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ABSTRACT 

This report is concerned with the problem of achieving flexibility 
(additivity, modularity) and efficiency (performance, expertise) 
simultaneously in one AI program. It deals with the domain of elementary 
electronic circuit design. The proposed solution is to provide a deduction- 
driven problem solver with built-in control-structure concepts. This problem 
solver and its knowledge base in the application areas of design and 
electronics are described. The program embodying it is being used to explore 
the solution of some modest problems in circuit design. It is concluded that 
shaI low reasoning about problem-solver plans is necessary for flexibility, and 
can be implemented with reasonable efficiency. 



PAGE 3 


Acknowledgments 

I thank Gerald Sussman, my advisor, for much good advice; Sussman and Allen 
Broun for help uith electronics; flitch Marcus and Charles Rich for ideas on 
control; Bob Moore and Arthur Nevins for predicate calculus; David Marr and 
Scott Fahlman for ideological consultation; my readers Marvin Minsky and 
Vaughn Pratt for useful comments; and Jon Doyle for careful reading and 
substantive suggestions in the later stages of this research. Marr, Patrick 
Winston, Guy Steele, and several others also made good suggestions to improve 
the organization of this uork. 

Finally, I thank Judi for, among other things, moral support; and myself 
for typing many drafts of uhat seemed like meaningless gibberish 



PAGE 4 


Contents 

I Introduction 7 

I.A The Problem 7 

I.B A Rule-Based Problem Solver 1G 

I.C Supplying Rules for Design 22 

I. D Relation to Previous Uork 33 

I.D.l Problem Solving and Reasoning 33 

I. D;2 Electronics and Design 33 

II Expressing Knowledge In NASL 43 

II. A The Natural History of Actions 4G 

I I.B Interpretation and Inference 56 

II. B.l The NASL Interpreter 57 

II.B.1.1 Selecting a Task to Uork On 57 

II.B.l.2 Executing Tasks 59 

II.B.l.2.1 Primitive and Problematic Tasks G0 

II.B.1.2.2 Primary and Secondary Tasks G3 

I I.B.2 STP — The Stupid Theorem Prover G4 

I I.C Choice and Rephrasing 71 

II.C.l The Choice Protocol 73 

II.C.2 Rephrasing 76 

II.D Dependencies Among Data and Tasks 78 

II.E Handling Mistakes 82 

II. F Programmer’s Guide 84 

II.F.l Predicate-Calculus Techniques 8G 

II. F.2 NASL Programming Techniques 88 

III Design of Hierarchical Systems 90 

III. A The Representation of Knowledge about Devices 99 

III. A.l Hierarchies of Device Types 99 

III.A.2 The Representation of Oevice Diagrams 101 

II I.B Design Actions and Plans 106 

III.B.l DESIGN 107 

11I.B.2 Making Things 112 

III.B.3 Constraints 114 

11I.B.4 Changing Devices 118 

11 I.C Composition of Partial Solutions 120 

11 I.D Constraint Collapse 121 

I II.E Programmer’s Guide 126 



PAGE 5 


IV Electronics 128 

IV.A Physics 128 

IV.A.l Connections and Constraints on Components 128 

IV.A. 2 Signals 132 

IV.A. 3 Multiple Models of Linear Systems 135 

IV .0 Electronic Design Knowledge 137 

IV.B.l Rephrasing Electronic Design Problems 137 

IV.B .2 Reconciling Partial Solutions 138 

IV.B. 3 Changing Circuits 141 

IV. B .4 Electronics Analysis Knowledge 145 

IV.C Device Schemata 14g 

IV. D Programmer’s Guide 148 

V Results 150 

V. A Using DESI 150 

V. A.l Loading and Running the Program 150 

V.A .2 DESI Talks to You 151 

V.A .3 You Talk to DESI 152 

V. B Experimental Results 153 

V.B.l A Simple Amplifier 155 

V.B. 2 Converting a Square Wave into a Sine llave 171 

V.B .3 NOAH in NASL 176 

VI Conclusions 178 

VI. A Successes 180 

VI.B Failures 186 

VI.C Further Work 130 


Appendix 1 — NASL Syntax and Informal Semantics 134 
Appendix 2 -- A Listing of DESI 202 
Appendix 3 — A Listing of ZORCH 21G 
Appendix 4 — Details of STP for Theorem Provers 251 


Blbllography 


255 



PAGE G 


Figures 


Figure 1.1 Redescribing a Design Problem g 

Figure 1.2 Two Circuits Suggested by Parts of the Problem 10 

Figure 1.3 A Cascade of the Two Partial Circuits 11 

Figure 1.4 Signal Conversion Problem 12 

Figure 1.5 Spectrum of Square Uave 13 

Figure I.G Spectrum of Sine Uave 13 

Figure 1.7 RC FiI ter ^ 

Figure 1.8 A Circuit for Adding a Pole 15 

Figure 1.9 Structure of DESI 23 

Figure 1.10 A Rephrasing Subtask 29 

Figure I.11 Rephrased Task Network 30 

Figure 1.12 Retrieved Circuit and Constraint Task Network 31 

• Figure 11.1 A Task Net, or "Plan" 50 

Figure 11.2 Task Network with Subnets 52 

Figure 11.3 Logical Taxonomies of Tasks 53 

Figure 11.4 Life History of a Task 58 

Figure 11.5 Enablement Relations in Subnets G 2 

Figure III.l Function-Structure Graph 92 

Figure 111.2 A Two-Stage Cascade 94 

Figure 111.3 An LC-coupled Amplifier 95 

Figure III.4 A Hierarchy of Types of Device Types 100 

Figure III.5 Devices in The Type Hierarchy ' 101 

Figure 11I.G Design Action Taxonomy 107 

Figure 11 1 .7 Design Rephrasing Plan Schema 109 

Figure 111.8 Rephrased Design 110 

Figure I I 1.9 Quantity-Value Protection Plan Schema 117 

Figure 1 11.10 Radio Spectrum With Two Stations 122 

Figure 111.11 Relevant Constraints 123 

Figure III.12 Constraint Network 124 

Figure IV .1 Terminals and Nodes 129 • 

Figure IV.2 Composite Device Terminals 130 

Figure IV.3 Inserting a Device into a Node 130 

Figure IV.4 Ports and Nests 131 

Figure IV.5 Fourier Transform of an Offset Square Uave 134 

Figure IV .6 Bias Plans 142 

Figure IV.7 General BJT Coupling Plan 143 

Figure IV .8 Common-Emitter Direct Voltage Coupling 144 

Figure IV .9 General and Specialized Emitter-Coupled Pairs 147 

Figure VI .1 Provinces of Artificial Intelligence 181 

Figure VI,2 The Rule-Based Utopia 182 




This empty page was substituted for a 
btank page in the original document. 



I Introduction 


7 


I Introduction 
I.A The Problem 

This thesis reports on the exploration of a classic AI controversy 
regarding the representation and use of knowledge: the trade-off between 
flexibility (or modularity or additivity) on the one hand, and efficiency (or 
expertise or performance) on the other. It focuses on the knowledge required 
for designing elementary electronic circuits. The conclusions I have reached 
are that this kind of f I exibi I i ty requires all important operations to be 
mediated by explicit rules driven by changes to an associative data base; and 
that the inevitable inefficiency of this organization can be controlled. The 
proposed approach has been tested by implementation of an extensible design 
program called DESI. 

The theory of design that I have implemented 13 based on the idea of 
"functional reasoning." (Freeman and Newell, 1971) A problem is stated as a 
property uhich an electronic circuit is to have. The system searches its 
memory for circuits whose known functions fit the requirement. In the 
attempt, it constrains the connectivity and component values of the circuit 
until enough constraints have accumulated to find values which satisfy the 
original property. This simple theory mu9t be complicated in various ways: A 
requirement may not be expressed in a form which triggers suggestions of 
familiar circuits; it may be necessary to transform the requirement until it 
does. More than one device type may be brought to mind in a situation; there 
must be criteria for deciding among them, or ways of synthesizing new circuits 
that perform the functions of all the ones retrieved. A suggested circuit may 
not work out; the theory must specify how plans are changed. 

I require that the embodiment of this theory be "additive"; that is, to 
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the extent possible that new knowledge be expressed by new formulas rather 
than by changes to old. This is partly because of the ease with which such a 
system can absorb new information; and partly because a creative designer 
requires the ability to see the individual parts of its various, often 
conflicting, plans and goals. For this reason, the theory is embodied as a 
"rule-based" system. 

By a "rule-based" system I mean a system which makes progress by pattern- 
driven operations on a data base. There are several paradigms for such 
systems; the classical ones are predicate-calculus theorem provers (Nevins, 
1974a), production systems (Newell, 1973a), and AI languages with pattern- 
directed procedure invocation. (Hewitt, 1972, Bobrow and Raphael, 1974) In 
what follows, I wi 11 attempt a synthesis of good features of all of these. 

The result may be described as a system in which plans are assembled piece by 
piece. The rules used resemble predicate-calculus implications. They differ 
in these ways: they may be used to infer what tasks are required or what 
solutions are possible; they are less constrained in the kind of inference 
rule and "self-referential" deduct ions al lowed; they specify how they are to 
be used; and they come in larger, better organized chunks than is traditional 
in predicate-calculus applications. 

Before elaborating further on these requirements, let me bring these 
problems to life with two examples from elementary electronic design, 
illustrating as I go hou DESI deals with them. The first example shows how 
choices must often be based on knowledge of current plans. The second example 
illustrates some of the other complexities I mentioned. (These informal 
scenarios are meant to give you a picture of the design problems DESI is meant 
to handle, not the structure of the program or its actual behavior. I will go 
over these problems again, once in this chapter to illustrate the 
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representation and use of knowledge by the system, and again in Chapter V to 
show the performance of the actual implementation.) 

Redescribing Problems and Choosing Solutions 

Imagine that DESI is given the problem, "Design an amplifier with an input 
resistance of 30 kohm and a voltage gain of 5." For now, let us assume this 
problem will be broken into the three subrequirements, "amplifier," "input 
resistance - 30 kohm," and "v-gain - 5." (This must be done with care, since 
these three characteristics are of rather different kinds.) This is only part 
of the problem, for these fragments of the original problem are too precise to 
be suggestive; DESI must further alter the description so that these numbers 
become "range descriptions" like, "high input impedance" and "moderate voltage 
gain." (See Fig. 1.1.) 

"amplifier with input resistance - 30 kohm and 
voltage gain - 5" 

\ / 

| | becomes 

I I 

V 

"amplifier" <- thing to make 

"input resistance 30k" <- high input resistance 

"voltage gain 5" <-- moderate v-gain 

Figure 1.1 Redescribing a Design Problem 
Once the problem has been described in this form, its fragments trigger 
suggestions of possible solutions. For example, in the context of making an 
amplifier, "high input impedance" should suggest "common^coI lector amplifier," 
and "moderate voltage gain" should suggest "common-emitter amplifier." (Fig. 
1 . 2 .) 
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high input resistance 

+V, 


.POWER 


cc 



high voltage gain p0WER 

+V CC > 



COMMON EMITTER 


Figure 1.2 Two Circuits Suggested by Parts of the Problem 
If just one of these had been suggested, the problem would be easy: DESI 
could select a standard schema for the type that came to mind and make sure 

t 

the given numerical constraints could indeed be satisfied. Uhat must it do 
when two or more options occur? In some cases, all but one may be excluded on 
the basis of further considerations beyond the simple problem features that 
suggested the competing options; often, however, what is required is a 
synthesis which combines two suggestions to provide the functions of both. In 
this case, DESI must possess information to the effect that an option 
suggested because of what it does for an amplifier’s input resistance may be 
"cascaded" with another option. 

So far, I have drawn these circuits as if they always contained the parts 
shown. However, the notions of "common-collector" and "common-emitter" 
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amplifier each corresponds to a range from general to specialized circuits. 
Uhen' a common-emitter amplifier slmpllclter is desired, the circuit of Fig. 

1.2 is selected almost uithout thought. But a practiced designer knows that 
the abstract idea" of this circuit may be realized in other uays. To cascade 
the two circuits of Fig. 1,2, OESI would not just "draw” the same two pictures 
•and cram them together in some way. Instead, it chooses more general diagrams 
of these circuits, and reconsiders how they are to be biased and coupled. 

Thi 9 will involve further choices. The result is the circuit of Fig. 1.3. 



Figure 1.3 A Cascade of the Two Partial Circuits 
Finally, the numerical constraints set aside in favor of more revealing 
descriptors are taken up again to give the component values shown in the 
figure. 
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Transforming Problem and Solution 

In this second example, I wish to show how much more complicated the 

phases of design can get. Imagine that the problem given is 

Design a netuork which converts a 1kHz square wave of amplitude IV into a 
sine wave with the same frequency and amplitude. 


1kH7 1kHz 



Figure 1.4 Signal Conversion Problem 

Even if you know nothing about electronics, it may be worth thinking about 
this problem for a minute before going on. (You don’t have to, but the 
problem can be amusing, and illustrates an interesting and common phenomenon 
of problem solving.) 
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If you know some elementary mathematics, it probably occurred to you to 
lake the Fourier series of each of these signals. In this "frequency domain," 
the problem becomes: 



1 2 3 4 5 6 7 8 9 10 11 12 13 

Figure 1.5 Spectrum of Square Wave 
into a signal with spectrum 


kH z 

1 2 3 4 5 6 7 8 9 10 11 12 13 

Figure 1.6 Spectrum of Sine Uave 
such that the amplitude of the spike at 1kHz is IV. 

If you know some electronics, it might then have occurred to you to try a 
low-pass filter circuit like 
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INPORT 



OUTPORT 


When used for low- 
pass filtering above 
cutoff frequency f. 


System Function = — 2. 

1 + RCs 

(if not loaded) 


Figure 1.7 RC Filter 

ae your ansuer, and then try as before to finish the problem off by assigning 
values to the primitive components (here, the capacitor and resistor) which 
satisfy the constraints we have discovered. 

The interesting constraints on this circuit may be stated as follows. 

flake the amplitude of the output spike at 3 kHz less than 10% of the 
amplitude of the output spike at 1 kHz." 

"Make RC be the reciprocal of the frequency 1 kHz (in rad/sec)." 

The ratio of the amplitudes of the outputs at two frequencies depends on 
the amplitudes of the inputs and the selectivity of a device." 

"The selectivity of an RC filter is ..." 

DESI can derive these constraints from the statement of the problem (starting 
uith a lot of knowledge about RC filters and frequency-domain operations). 

Unfortunately, these constraints cannot be solved simultaneously. The 
circuit given will make a square wave look "rounder," but the approximation to 
s sine wave will not be good enough. The constraint that deserves the blame 
in this case is that on the selectivity of an RC filter. How can this be 
improved? One way is by "adding a pole" to it9 system function with this 
circuit: 


it 
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A 




New 

OUTPORT 


New system function = old x 
(Remember to implement A.) 


1 

f+ R'C s 


Figure 1.8 A Circuit for Adding a Pole 

This makes DESI s vieu of the solution much more promising. (I won’t pursue 
this example any further, because the current implementation lacks the 
competence to go any further.) 

Let me list the various types of information that I appealed to in my 
brief overview of how such problems may be solved. First, DESI needs 
knowledge about transforming the problem into a tractable form; this ranges 
from a relatively simple sorting out of multiple requirements, to a more 
difficult transformation from a time-domain to a frequency-domain description 
of a problem. Second, and quite important, there had to be a basis for 
choosing among more than one approach. Third, several constraints had to be 
satisfied in a consistent way. This required knowledge of the physics of 
electronic circuits. Fourth, ue had to be able to change plans when our first 
try failed. 

To make all these kinds of information usable, DESI has to be able to 
reason about its current plans and goals. Transforming a problem may be seen 
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as redescribing the topmost goal. Choice of a solution to one problem often 
depends on the other problems under consideration. The calculation of a 
design quantity to satisfy one constraint is pointless unless all the other 
constraints on that quantity are taken into account. And, of course, one 
cannot change plans without knowing what they are. An organization which 
makes using such knowledge practical has been the goal of this research. 

I.B A Rule-Based Problem Solver 

Here is my thesis: problems are solved by reducing them to subproblems. 
Some of these subproblems result in action, others in constraints on action. 

As the solution progresses, the way in which new subproblems are approached 
depends more and more on the state of other subproblem solutions, that is, on 
the requirements derived from the physics of the evolving solution and on the 
goal structures that have already been elaborated. It is impossible to know, 
as new facts are discovered, what subsequent subproblems will depend on them, 
90 a I I such facts must be stored in the same communal data base and accessed 
whenever they become relevant to a later problem reduction. 

This is accomplished by implementing OESI as a set of rules manipulated by 
a rule-based problem solver called NASL. A rule-based system (Shortliffe, 
1976, Davis and King, 1975) is one in which knowledge is expressed as 
conceptually small units called rules. 

There are two sources of inefficiency in a system organized this way: the 
overhead paid for storing almost all knowledge in the same associative data 
base, and the nondeterminism inherent in the possibility that more than one 
rule may apply to a problem. The first kind of inefficiency is the price of 
flexibility, but it can be limited by proper organization. One important 
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principle of organization is allow rules to come in we 11-organized chunks. In 
-DESI; these "packets" of rules (McDermott, 1975) are used to represent circuit 
diagrams, signal descriptions, partial plans for solving problems, and groups 
of rules for making choices. 

The second source of inefficiency, nondeterminism, can be controlled by 
confining it to the information retrieval module. Above this louest level, 
potential nondeterminism is shut off by applying "choice rules" in ambiguous 
situations. 

In this section and the next, I will sketch the form and content of DESI’s 
rules. This sketch will be filled in in Chapters II, III, and IV. Chapter V 
gives the results that have been obtained by implementing it. 

In any rule-based system, each rule i3 associated with a pattern by which 
the system accesses it. The system also maintains a data structure, the 
"active processing site," that is intended to describe important aspects of 
the current situation. Rules are matched against this structure, and rules 
whose patterns match are applied in some way. 

The potential advantages of a rule-based system are these: (1) the system 
can see what it is doing because important steps occur at standard times in a 
standard way; (2) the system can keep track of its deductions and/or actions 
in order to explain or undo them; (3) the system can be augmented simply by 
adding new rules. 

Realizing these potential advantages has not been easy. There are three 
classic types of rule-based systems: 

(1) Predicate-Calculus Theorem Provers — Here the rules are axioms and 
the currently active processing site is that rule which is being treated as a 
goal. Applying a rule generates new rules or answers to the problem at hand. 
(Robinson, 1965, Nilsson, 1971, Nevins, 1974a, R. Moore, 1975) 

(2) Production Systems — Here the rules are condition-action pairs, or 
"productions," and the current site is a small list called the "Short-Term 
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Memory," or STM. Applying a rule consists of performing manipulations on the 
STM or doing simple input/output operations. (Rychener, 197G, Newell, 1973a) 

(3) Artificial Intelligence Programing Languages — These languages may 
be said to be rule based if pattern-directed procedure invocation is taken as 
rule application and if such procedures are taken as rules. The processing 
site is a flexible record-oriented data base, in particular, the records 
currently being added, deleted, or retrieved. These languages include PLANNER 
(Hewitt, 1972) and its descendants QA4 (Rulifson et. al., 1972) and Conniver 
(Sussman and McDermott, 1972). 

(More specific examples will be mentioned for comparison with NASL later.) 

All of these systems have suffered from problems which have kept them from 
realizing their potential. The predicate-calculus systems are the least 
deterministic of the group. The control of application of predicate-calculu3 
rules has not itself been rule-directed or directed by much knowledge of any 
kind. However, one of their strong points is that the proofs they generate 
play a natural role in keeping track of their actions or justifying them to a 
human user. 

Production systems have very low-level rules. The system provides simple 
symbol-manipulation ability, but each programmer must provide his own control 
concepts, starting at the level of the subroutine call. This tends to defeat 
real extensibility, since two sets of rules probably have different calling 
conventions. (Production systems have been evolving toward greater richness.) 

AI languages provide more direction and control over problem solving, but 
at the cost of making "rulishness" only a token aspect of procedures. The 
small patterned interface between a program and its callers is usually dwarfed 
by the body of the procedure. Other procedures know that this one is there, 
but they do not know what it is doing. 

A general problem of all these systems is that they are insensitive to 
important aspects of their own operation. Production systems and pattern- 
directed procedures generally do not manipulate themselves. (That is, systems 
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built on them do not encourage or simplify this any more than the LISP 
interpreter in which they are generally embedded.) 

To remedy these defects, I have implemented the NASL rule-based system to 
depend heavily on explicit representation of control. NASL’s active 
processing site is a PLANNER-type data base of rules, but more is stored there 
than in the typical Al-language system. Besides a model of the current 
problem situation, the data base includes a representation of the "current 
plan." Rules are used, not to trigger actions directly, but to add tasks to 
this representation. Uhen the rules are used in a forward-deductive way, they 
resemble productions, with an extra layer of "carefulness" between application 
of the rule and actual execution of the task. (Sussman, 1975) Uhen the rules 
are used in a backward-deductive way, when the interpreter is attempting to 
find a way of carrying out a task, they augment the plan much the way a 
PLANNER-like language invokes procedures. 

The difference between a plan and a procedure is that a plan may represent 
action at a more abstract level. In particular, the order of steps within and 
between subplans is itself rule-governed. Furthermore, not all tasks 
correspond to subroutine calls to bring something about or calculate 
something. Some tasks are intended to represent "parasitic" actions which 
influence the execution of other tasks, or which require occasional commitment 
of resources. Examples from circuit design are the actions, "Constrain RC to 
be l/2nf, " "Hake sure every requirement in the given design problem is 

accounted for," and "Take note of the high-gain requirement in making this 
amp Iifier." 

These secondary tasks, or "policies,- are particularly useful in choice 
situations, in which the problem solver tries to decide among more than one 
course of action. The existence of a policy often amounts to the existence of 
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certain rules for suggesting options or deciding among them. 

Another important difference between Al-language procedures and NASL plans 
is that plans are completely deterministic. All search is done in the rule- 
appliers that try to retrieve, construct or choose among plans. If the 
resulting plan does not work, a "mistake correction" plan must be sought which 
Is appropriate to the kind of mistake that occurred. 

Inability to retrieve a solution plan via the simple deductive retrieval 
mechanism does not cause any kind of "failure." Instead, the system attempts 
to transform, or "rephrase," the problem until it is in a more familiar form. 
This requires that the rules and records of the system be man i pul able by 
rephrasing tasks. 

To explain its actions and correct its mistakes, the system must keep 
records of why it did yhat it did. These are of two kinds: stored chains of 
rule applications, and relations between tasks. The user may ask for an 
explanation of a task in terms of the tasks it was designed to accomplish. 

The system may edit these networks of relations when it runs into trouble. 

I mentioned at the beginning of this section that rule-based systems are 
potentially "extensible," that is, able to accept new information additively, 
without major reorganization. Ue can distinguish short- from long-range 
extensibility. Over the long range, putting new information in is part of a 
simple but important kind of learning— "taking advice." It is not the only 
part, because reorganizing descriptive structures and debugging or 
disambiguating what one is told are also crucial. 

Therefore, it is easier to see the importance of extensibility over the 
short range. It is common in AI research these days to assume that knowledge 
is represented in large, we I I-organized chunks (usually called "frames"). 
(Minsky, 1974) Assuming this to be true, we still have the problem of 
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interactions of two simultaneously active chunks. This is just the 
extensibility problem in the small, since each chunk appears to the other to 
contain new information that may be relevant. Unless all frame interactions 
have been foreseen in advance (which is normal in most computer science, but 
not in AI), the information in each chunk must be expressed in terms the other 
can understand. (This is why programs appear to me to be such a poor frame 
representation, since a program is just a large chunk of lines of code, none 
of which means anything outside of its particular context.) At the very 
least, a system must notice potentially relevant interactions and ask for 
further information when it does. 

In NASL, each rule resembles a Skolemized formula of predicate calculus. 
(Robinson, 19G5) (In fact, few substantive restrictions on predicate calculus 
have been preserved in this notation.) The rules are manipulated by a 
PLANNER-1 ike theorem prover. (Cf. R. Moore, 1975) However, the rules can come 
in large chunks called "packets." (McDermott, 1975) Packets can include other 
packets (since they are logically just large conjunctions of formulas). One 
use of this is the implementation of hierarchies like those of "semantic 
network systems. (E.g., Bobrow and Winograd, 197G) Circuit diagrams, among 
other things, are stored as packets. 

There are several "framish" concepts used in implementing NASL. For 
example, the active tasks of the current plan might correspond to the 
"important questions" terminals of a Minskian frame. (Minsky, 1974) However, I 
have felt free to diverge from the orthodox conventions of frame theory, and 
one must not assume that "plans" or "packets" correspond directly to frames. 
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Design Electronics Current Data 

Knowledge Knowledge Pool 



STP -| NASL Plan Interpre 

/\ / \ 


EVAL 


CHOOSE 


REPHRASE 


Figure 1.9 Structure 

of DESI 


The program, loosely known as OESI, has the following hierarchical 
organization (from the bottom up): 

STP — A PLANNER-like theorem prover 

EVAL, CHOOSE, REPHRASE — non-standard inference mechanisms 

NASL — The interpreter for plans 

DESI (proper) — A set of rules for designing hierarchical systems 

ZORCH — Rules embodying electronics knowledge 

The rules themselves are highly structured. Some of them specify physical 
relations among things like nodes and signals. Higher-level rules are used to 
influence problem choice and transformation. Almost all of them have some 
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procedural component, in that they refer to the current task network. For 
example, even the simplest statement of Ohm’s law, that the current through a 
resistor equals its voltage over its resistance, is stated as a constraint on 
the values of these physical quantities. 

Host of the "raw information" in the system is stored in packets defining 
known circuits, such as common-emitter amplifiers, voltage dividers, etc. 

When a circuit of a given type is created, its packet will be instantiated. 
Each such packet contains information of these kinds: 

(1) Component definitions like 

[COMPONENTS ?##V0LTAGE-0IVIDER 

<(R1 ?##VOLTAGE-01VIDER) (R2 ?##VOLTAGE-DIVIDER) >] 

(NASL formulas are always enclosed in [brackets]. See Appendix 1 for details 
of this and subsequent NASL notation. The prefix "?" indicates a predicate- 
calculus variable; in a packet, "?##X" refers to an object that will be bound 
later to a particular instance of the concept the packet describes. 

(McDermott, 1975). Angle brackets enclose tuples.) 

(2) Connection specifications like 

[NODES ?##V0L TAGE-DIVIDER 

<(TOPNODE ?0#VOLTAGE-DIV!DER) 

(MIDNODE ?##VOLTAGE-DIVIDER) 

(BOTNOOE ?##VOLTAGE-DIVIOER)>] 

INODE-TERM INALS (MIDNODE ?##V0L T AGE -DIVI DER) 

<(#2 (R1 7MV0LTAGE-0IVIDER)) 

(#1 (R2 ?##VOLTAGE-DIVIDER))>] 

(3) Constraints and other "frozen tasks" which will be awakened when an 
instance of the packet is created. These are used to associate with a device 
a description of its purposes and further requirements. The commentary 
appearing around the diagrams in Figs. 1.2, 1.7, and 1,8 is represented as a 
set of such tasks. 

These circuits come in hierarchies of various kinds. The components of a 
circuit may themselves be circuits. Circuits may be arranged in classes (such 
as "amplifier") which share properties. One circuit may be derived from 
another by assuming special conditions; for example, the specific and general 
common-emitter circuits I pointed out in Sect. I.A are of this type. All of 
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these hierarchies may be represented by the device of allouing packets to 
include other packets. 

A solution to a design problem is represented as a structure of 
instantiated circuits, with primitive-component values selected. A top-level 
design problem is of the form, "Find a circuit structure with property...." 

It is the information required to go from property to circuit that is of 
most interest. This falls into several classes: (1) knowledge about 
transforming problems, (2) rules for making choices, (3) plans for altering 
and improving circuits, and (4) knowledge about physical constraints on 
quantities. Each of these categories is represented by rules in DESI and 
ZORCH. DESI is a small set of design rules that are intended to be 
independent of any one physical domain; it provides a vocabulary and task 
structure within which ZORCH's rules can operate. 

For example, OESI provides a standard framework for rephrasing design 
problems. The idea is to transform an unfamiliar design problem into the 
making of a familiar kind of circuit obeying physical constraints, using more 
suggestive hints like "make it linear" or "notice the high gain." (Cf. Sect. 

I.A.) ZORCH provides rules to do this decomposition and then to use the hints 
and constraints to zero in on a diagram. 

The DESI rephrase plan contains tasks to 

"Explode" the given property into "shards." 

Classify shards as to whether they suggest a familiar device type, a 
constraint, or a "design features" like "linearity." 

Gather the suggestions into a neu task network. 

In this process, rules like this (from ZORCH) become important: 
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[-/> A (D-SHARD ?+P t* (_?+V) (- (V-GAIN (/?/? _?+V)) _?+G)I) 

(-/> G (/> (DEN ?+G) 50) 

(D-FEATURE ?+P [RANGER V-GAIN HIGH)))] 

This says that a voltage gain greater than 50 should be noticed as "high. 

The symbol signifies implication; the letter after it identifies the way 

in which the rule is to be used. (See Chapter II. The "A" means when the 

left side is recorded, record the right; the "G" means call the theorem prover 

to find answers to the left side, and record the right side for each 

substitution returned. The actual rules in Appendices 2 and 3 are more 

indirect and give more information.) 

Once the task network has been transformed, other ZORCH rules come into 

play. These rules are of these kinds; (1) definitions of fundamental wiring 

operations; (2) physical laws like Ohm’s which constrain numerical quantities; 

(3) plans and pieces of plan for biasing, coupling, and performing other 

standard operations on circuits; (4) rules for choosing among sub-types of 

inclusive circuit categories suggested by the rephrase rules. 

Fundamental wiring operations are defined using the built-in relation 

/:MOD-NANIP (for "model manipulation"). For example, connecting terminals to 

form nodes may be defined by this rule 

[/sMOD-MANIP 7TASK (CONNECT ?T1 ?T2) <> 

<’ (EXISTS (N) (AND (DEV-TYPE ?N NODE) 

(NODE-TERNINALS ?N <?T1 ?T2>)) )>). 

This defines an "addlist" (Fikes and Nilsson, 1971) for this action. (Its 
"deletelist" is empty.) 

Physical laws are defined by rules like this: 
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E-/> A (DEV-TYPE ?X RESISTOR) 

(EXISTS (T) 

(/sTASK ?T <> 

(X 0 (CONSTRAIN <’ (V ?X) MI ?X) MR ?X)> 

(X (V I R) (= ?V (* ?I ?R)) ))) 

<>) )] 

which commit3 the designer to the given constraint. CONSTRAIN is a kind of 
policy action defined in DESI; again, DESI provides the vocabulary for ZORCH. 

Choice rules are used for differential diagnosis or synthesis of partial 
solutions. For example, in choosing an amplifier, the rule 

[-/> A (/:0PTI0N ?C ?A1 [/:TO-DO _?+TASK (flAKE AflPLIFIERI <_?+AMP> 

(MAKE COMMON-COLLECTOR)]) 

(-/> A (/{OPTION ?C ?A2 

[/:TO-DO _?+TASK (MAKE AMPLIFIER) <_?+AMP> 

(MAKE COMMON-EMITTER))) 

(/{RULE-TOGETHER <?A1 ?A2> 

C/:TO-DO _?+TASK (MAKE AMPLIFIER) <_?+AMP> 

(MAKE (CASCADE COMMON-COLLECTOR 

COMMON-EMITTER))]))] 

This rule says that a common-collector amplifier and common-emitter amplifier 
may be cascaded to accomplish the purposes of both. (The actual rule comes 
closer to saying this.) The conclusion (/:RULE-TOGETHER...] is used by the 
choice protocol of Fig. 1.9. It is used to specify composition of separately 
unsatisfactory choices; /;RULE-IN and /sRULE-OUT are used to narrow the list 
of options. 

Many aspects of the operation of the system cannot be brought out by this 
kind of summary. In the next three chapters, I will describe its knowledge 
more systematically. The major omission so far has been a good description of 
the task network and its evolution. Without this description, much of the 
content of the rules is lost. 

To compensate, let me sketch DESI's behavior on the second problem I used 
as an example in Sect. I.A, indicating points of interest as I go along. The 
problem is presented as the problem of designing a circuit to convert signals 
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satisfying an input predicate to those satisfying an output predicate. (See 
Chapter IV.) Thi9 is written 

[DESIGN 
(A (CKT) 

(CONVERT ?CKT 
(A (IN) 

(AND (PERIODIC (TFUN ?IN) 10.0E-3) 

(FORALL (T) 

(AND (-/> C (/< ?T 0) 

(= ((ONE-PERIOD (TFUN ?IN)) ?T) 

1)1 

(-/> C (NOT (/< ?T 0)) 

(- ((ONE-PERIOD (TFUN ?IN)) ?T) 

- 1 ))) )) ) 

(A (IN OUT) 

(- (TFUN ?0UT) (A (T) (SIN (* 2000 PI ?T)) )) )) )) 

The input predicate is just a time-domain definition of "1kHz square nave." 
The output predicate defines the time function (TFUN) of the output to be a 
9ine wave. (C after "-/>" means: to prove the right-hand side, detach the 
left as a subgoal.) 

The design problem is used to start a task network or plan. The goal of 
the problem solver is to accomplish every extant task. In the course of doing 
this, subtasks of various kinds may be generated, which must be gotten rid of. 

In the case at hand, the complicated design problem does not match any 
stored subplan directly. The resulting failure of the theorem prover causes 
the NASL interpreter to 9et itself the task of "rephrasing" the design task. 
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Q design... 

i — 

vJ super-task 



make 
r\ design 
^ subnet 


Figure 1.10 A Rephrasing Subtask 

This rephrasing process notices the conversion problem in the description 
of the desired circuit, and spends some time trying to calculate and compare 
the frequency spectra of the input and output signals. This process results 
in the re-description of the problem as a low-pass filtering problem. (The 
complex details of this example are described in Chapters IV and V.) 

This operation of rephrasing the original problem is carried out by the 
NASL interpreter, operating at a different logical level. In particular, it 3 
behavior is rule-governed in the same way. The only difference is that 
problems at the lower level become objects of manipulation at the higher 
level. The result of this manipulation ultimately appears as a new problem 
network at the original level. 

The signal descriptions I showed earlier are subject to rules from ZORCH 
which suggest looking at them in the frequency domain (Figs. 1.5 and 1.6), and 
looking for a simple transformation between them. The transformation 
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discovered, namely [LOU-PASS 1000], generates the design shards 

• [X (CKT) (DEV-TYPE ?CKT LOU-PASS-FILTER)1 
[X (CKT) (- (LOU-CUTOFF-FREQ ?CKT) 1000)1 

which in turn suggest a basic device type (low-pass filter), constrained to 

reduce its output at all frequencies above 1 kHz to negligible values. 

The task net has now been "elaborated" to the structure of Fig. 1.11. 


q design. 


make a ^ 
low-pass O 
filter 



_ constrain 

O it... 


Figure I.11 Rephrased Task Network 

The problem has become "make a low-pass filter, and constrain it to fit the 
exact desired characteristics." The first subproblem in this structure i9 
much simpler than the original, and results in the retrieval of a useful plan, 
in the form of a "device schema" for an RC f i I ter. (I will defer the 
possibility of more than one schema being brought to mind until later.) 
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"Frozen constraints" 
on R, C and System Function 


Figure 1.12 Retrieved Circuit and Constraint Task Network 
The problem now (see Fig. 1.12) is to satisfy the constraints given. Some 
of these came with the problem statement, but many more tag along with the 
schema for RC filter (which includes facts about filters in general). A 
useful feature of the NASL language is that we can express the purposes of 
devices in the same language the system uses to express its own: as tasks. To 
use an RC filter is to insist that its resistor and capacitor have values 
compatible uith its desired system function. Such tasks are called "frozen 
policies ." 

Such already established tasks are not the only useful kind that ride 
along in device schemata. There are also "expansion obligations" which remain 
to be done. An example of this technique is the definition of "active 
transistor," as a "raw" transistor plus the commitment to bias it in whatever 
context it appears. In the case of the filter, the only expansion obligations 
are to select values for the primitive components. These tasks (see Fig. 

1.12) are carried out by interactions with the new and frozen constraints. 
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(In the current implementation, most algebraic symbol manipulation is carried 
out by the human user.) Values are to be found which satisfy all the 
constraints. When they are found, the fact that they satisfy the constraints 
is to be "protected." (Sussman, 1975) This can be a complex task in itself. 
(Chapter III.) 

As we saw before, there are no values which satisfy all the constraints. 
Even for engineering purposes, an RC filter cannot quite do the job. In this 
case, a failure occurs, which causes the insertion into the network of a 
correction task. This task may have to edit the task network as uel I as the 
current circuit model in order to solve the design problem adequately. (The 
current implementation stops before this point.) 

I have glossed over the problem of choice in this example. It is more 
obviously relevant in the case of the first example of Sect. I.A, designing a 
buffered amplifier. In this case, rephrasing is relatively simple, being a 
matter of unpacking a lambda expression such as 

IX (X) (AND (DEV-TYPE ?X AMPLIFIER) 

(- (V-GAIN ?X) 5) 

(- (INPUT-R ?X) 30080))). 

However, these fragments suggest more than one kind of amplifier, as we saw. 
(Fig. 1.2) In other words, the system has converted a problem with no 
apparent solutions into a problem with two apparent solutions. This 
embarrassment of riches is handled by invoking the choice mechanism, a simple 
"protocol" for calling the theorem prover. In this mode, a series of staccato 
deductions are made which attempt to rule out alternatives, vote in favor of 
alternatives, or synthesize new ones. (See Chapter 2.) The relevant rule is 
the one that says, "if you are trying to choose among different ways of making 
an amplifier, and option 1 was suggested because of its input resistance, and 
option 2 for some other reason, replace these options uith [CASCADE joption 1| 
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loption 2|]." (A simplified version of this rule appears above.) 

Other choices that occur in these examples are handled similarly. There 
.8 a rule that the general common-emitter circuit is the starting point for 
implementing a common-emitter coupled to something else. In the second 
example problem, if the system is ever told about LC filters, we will also 
have to give it rules like 

Use an LC filter if the power involved is high." 

"Other things equal, don’t use an inductor circuit if you can help it." 

For DESI s actual behavior on these problems, see Chapter V. 

1.0 Relat ion to Previous Work 
I.D.l Problem Solving and Reasoning 

The problems I am attacking in this research are not new. The problems of 
generality vs. expertise were originally studied by Allen Newell and his 
coworkers around I960. (Newell, 1962) Their efforts produced a "General 
Problem Solver which we have been trying to debug ever since. (Ernst and 
Newell, 1969) GPS was a "means-ends analysis" problem solver which applied 
state transformation operators to bring it to its goal. NcCarthy (1959) gave 
us the term "advice taker" to describe a program which can take new 
information and use it to do better. The creation of such a program is still 
my long-term goal and, in a sense, that of most other researchers. 

While this research was in progress, a tide of "rule-based" AI programs 
isos risen which NASL seems to be a part of. Its ancestors are the systems I 
described in Sect. I.B. More recent, special-purpose rule-based systems have 
sought to overcome their limitations. Shortliffe’s (1976) MYCIN is a limited 
but elegant medical-diagnosis system which uses a backward-chaining deductive 


I! 
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system. Sussman and Stallman’s (1975) EL does electronic circuit analysis by 
forward deduction. Both of these systems keep a record of deductions. EL 
uses these records to rethink deductions based on unworkable assumptions. 
(Stallman and Sussman, 197G) Both systems use them to explain their deductions 
to a human user. 

The NASL system differs from these in that its control language is aimed 
at a higher level of abstraction. Its rules, expressed in a predicate 
calculus, specify conclusions rather than actions. Action is achieved by 
having certain conclusions be interpreted as "required tasks" by the action 
interpreter. The notion of "task" is intended to be very inclusive. 

MYCIN and NASL can both be given neu rules, which, if they are not buggy, 
interact with the rest of the system in efficient ways. However, MYCIN’s rule 
language is deliberately restricted to the domain of fault diagnosis in poorly 
understood systems. (Davis et. al., 1975) (MYCIN is superior to NASL in 
having a more developed procedure for graceful assimilation of new rules. 
(Davis, 1976)) EL’s rules have stylized LISP code bodies. They can do 
anything, in principle, but the system functions most elegantly when organized 
around the satisfaction of numerical constraints. MYCIN does almost entirely 
backward chaining during deductions EL, forward chaining. 

The most important conceptual problem I have found in working on NASL is 
the requirement that the control structures of a problem solver ought to be 
simple enough to be inspectable, but contain enough higher-level concepts to 
be useful when inspected. The MYCIN group express this as a demand for 
"stylized programming" (Davis et. al., 1975). They have achieved impressive 
results in two areas. First, by use of "meta-rules," their diagnostic program 
can guide its own flow of control. This is something like my "choice 
protocol" in which NASL uses choice rules to decide hou to proceed. Second, 
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their knowledge-acquisition program knows enough about the "stylization” to 
participate in writing and debugging new rules. I shall make a more detailed 
comparison of these two capabilities with actual and potential abilities of my 
program in Chapter VI. 

The main limitation of MYCIN’s style of rule-based programming is that it 
i3 wholly oriented toward making tests and letting them "cast votes" for a 
result. There is no concept of planning or even acting. Davis et. al. 

(1975) acknowledge that for a domain with a more precise theory than medical 
diagnosis, a different control structure is called for. I hope DESI is an 
example. 

Stallman and Sussman’s (197G) EL is implemented using a language called 
ARSE which is embedded in LISP. The primitives in ARSE implement a system of 
forward deduction and "guessing," aimed toward finding a consistent assignment 
of variable values in a constraint network. ARSE has been used experimentally 
on other tasks involving constraints (Mason, 197G, Doyle, 197G), and so has 
modest pretensions to generality. ARSE’s control structure is formally close 
to NASL s (and helped inspire it). ARSE maintains "demon queues" generated by 
ongoing deductions. However, EL lacks the need or power to inspect these 
queues efficiently. NASL embeds the control structures in an associative data 
base, and generalizes the notion of queue to a task network. 

In this respect, the closest control structure to NASL is Sacerdoti’s 
(1975) NOAH. This is a brilliant program for planning a mechanical assembly 
and advising a person carrying it out. The planning part constructs a 
hierarchical network of ever more detailed plans. These plans are not 
programs? in particular, they do not have to be totally ordered. As parts of 
the plan are expanded, their interactions with each other are noted and 
corrected for by enforcing orderings. 
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The main difference between this part of NOAH and NASL is that-NOAH is a 
pfan compiler, while NASL is an interpreter; that is, it expands and executes 
pieces of plan as it goes. This is necessary because NOAH has a simple 
STRIPS-Iike (Fikes and Nilsson, 1371) assumption about actions which NASL 
doesn’t share. In particular, NASL is not as sanguine as NOAH about expanding 
a future action, because it has a limited model of the world at that point. 

It does not attempt to summarize the effects of all tasks as state changes, so 
it cannot have a domain-independent algorithm for checking interactions 
betueen steps. In particular, actions like "Design..." and "Constrain..., 
whose effects depend on how they are carried out and/or what else is being 
executed, do not fit into Sacerdoti’s framework. This makes room for more 
sophisticated knowledge about action, but it is a pity that I cannot use 
Sacerdoti’s simple and (within their limits) powerful algorithms. 

I have also profited from reading papers by Nilsson (1373) and Philip 
Hayes (1375) on interleaving planning and execution. Several researchers 
(Schank and Abel son, 1375, Abelson, 1375, Rieger, 1376, Charniak, 1375) have 
done research on classification of plans analogous to my taxonomies of Chapter 
II. Usually, however, they have been more concerned with analyzing narratives 
than uith actually solving problems, which has led to different criteria for 
classification. Perhaps some synthesis of these approaches will be possible. 

A class of systems with which NASL shares certain properties are the 
"utility" AI systems which have appeared recently. These are systems which 
provide data and control representations for users, who are expected to use 
these facilities for problem-specific programs. Examples are the AI languages 
(Bobrow and Raphael, 1373), Bobrow and Uinograd’s (1376) "Knowledge 
Representation Language," and Srinivasan’s (1376a,b) "fleta Description 
System." The AI languages provide assertion-based data bases like NASL’s. 
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(NASL and STP are descended in this direction from the AI language Conniver. 
(Sussman and McDermott. 1972)) The other two systems are more semantic-network 
oriented. (Uoods, 1975) This is in many ways merely a formal difference. 
Other differences between these research efforts depend on healthy differences 

of focus. For example, the KRL group is more concerned with recognition 
problems than I have been. 

A bigger philosophical difference is that NASL is an attempt to provide a 
P ' an descr 'Pt'on language rather than a programming language. The distinction 
may be wholly metaphysical; however, I believe that several features of NASL 
plans, especially the notion of "policy," if implemented properly, belong to 
plan description rather than programming. A concrete distinction between NASL 
and the traditional "AI utility" (Hewitt, 1972) is that NASL, far from 
requiring a program to specify a piece of knowledge, requires a body of 
knowledge to specify a program. I believe that Srinivasan’s MDS results from 
a similar orientation, but he is more concerned with general puzzle solving 
than capturing the knowledge in a rich domain. 

In any case, the older, less pretentious A! languages are the only members 
of this list of systems (NASL included) which are mature enough for their 

flaws and strengths to be visible. Which features of the newer systems will 
endure remains to be seen. 

Unlike most of the problem solvers mentioned, NASL uses a theorem prover 
to do sophisticated deductive information retrieval. This use of theorem 
provers has been suggested by many people. (Travis et. a?., 1972, Darlington, 
19G9, Moore, 1975) My theorem prover, STP, resembles most closely that of 
Nevins (1974a), with features from the work of Bledsoe (1975) and Ernst (1971, 
1973). Those familiar with the theorem-proving literature will enjoy Appendix 
4, which describes its features. 
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Other people have studied someuhat different uses of theorem provers in 
problem solving. (E.g., Fikes and Nilsson, 1971) In the past couple of years, 
one group of people has been urging the use of a predicate-calculus theorem 
prover as the only interpreter of a problem solver. (Kowalski, 1973, 1974, 
Uarren, 1974, Hayes, 1973b, Tarnlund, 1975) I think this vieu is misguided. 
Generally one does not go very far with this approach before he starts adding 
corruptive features, such as ordering the axioms, putting in dummy predicates 
to control search, allowing rules to refer to formulas, etc. (Uarren, 1974) 
fly conclusion was that it is better to admit defeat from the start, so I put 
control features in as concepts manipulable by the calculus and defined by the 
interpreter, and tried to preserve some of the purity of the theorem prover 
itself. I shall have more to say about the success of this attempt in the 
conclusion. 

I should mention that the concepts of action and decision have concerned 
philosophers for hundreds of years. Recently, a uhole branch of analytic 
philosophy has sprung up around them. (Langford, 1971, Brand, 1970, Danto, 
1965, Goldman, 1970) Many of the workers in this field have interesting 
things to say about the logic of action. For example, the computer 
scientist’s notion of a "primitive" is reflected (somewhat dimly) in 
statements like, "... those actions, ... performed by fl, which he cannot be 
said to have caused to happen ... I shall designate as basic actions." (Danto, 
1965) Unfortunately, these philosophers are much too reluctant to imagine 
that the mind behaves like a device with a real structure; all of their 
definitions are in terms of phenomenological rather than technological 
categories. For example, Goldman (1970) gives the following exegesis of the 
notion of "basic action": A basic act is an act A such that "if S wanted to 
exemplify A (at t), he would exemplify A (at t)." He then must spend no 
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Iittle effort 
philosophers 
in this field 
constructs. 


explaining away paralytics. I think that in the long run 
exposed to AI ideas are most likely to arrive at useful concepts 
by explaining want" and "act" in terms of hypothesized internal 


I.D.2 Electronics and Design 


The usual problem domain for a researcher with my pretensions is some 
class of puzzles (Ernst and Newell, 1969) or "narrative understanding." 
(McDermott, 1974a, Charniak, 1972). I have chosen elementary electronic 
circuit design instead, for these reasons: 


„ (1> 33 broad and sloppy a domain as "story understanding." One 

can reach critical mass” with a data base much faster. There are clearer 
critena for success. Electronics involves, I hope, as feu mental competences 
as possible in an interesting domain. 

T,, * 2) ? n the °* her hand ’ there i3 room for a variety of kinds of knowledge, 
(he domain cannot be, and doesn’t have to be, represented fully by a state 

3 ! e ^. 0f oper f tors - Puzzles are both too easy and too hard at once; 
they are probably a misleading example of problems that succumb to human 
thinking. 


(3) The subject matter is already formalized to some degree, so that I can 
focus on formalizing the control knowledge that is necessary. 


(4) 

requires 

presumab 


E ectronics is simpler than other engineering domains in that it 
less knowledge of space, time, and motion. Expertise in these areas 
ly drau3 on innate abilities we have difficulty bringing to light. 


i 5 . res ® arch has had the benefit of being part of an ongoing MIT AI 
laboratory project in automating electronics reasoning. Concepts used bg 
Sussman and Stallman (1975), Stallman and Sussman (1976), and A. Broun (1975) 
have been taken over, sometimes with some modification, into DESI’s knowledge’ 
base. (This is especially true of the parts concerned with signal description 
and electronic analysis.) 


(G) My wretchedness as an electrical engineer should make it easy to 
construct a program as good as its creator. 

The main drawbacks to electronics are 

(1) It is somewhat inaccessible to the average AI researcher or 


II 
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psychologist. People lose interest in documents regarding something they knou 
little about. (Uho knows what DENDRAL (Buchanan et. a7., 19G9) really does?) 

I ■ have tried to keep large sections of this text independent of electronics. 
Only Chapter IV and Appendix 3 rely on it. 

(2) Electronics knowledge as presented in introductory texts leans on 
spatial representations to some degree, even if not as much as other branches 
of engineering. Frequency-domain manipulations and pole-zero plots are 
examples of this. I have tried to preserve the structure of this knowledge in 
formal expressions (see Chapter IV), but I am aware that humans probably use 
more "wired-in" modes of spatial reasoning, whatever that may turn out to 
mean. I doubt that one could choose a better domain than electronics for 
avoiding this problem, however. 


My knowledge of electronics is mainly derived from books. (Senturia and 
Uedlock, 1975, Hayt and Neudeck, 1976, Uatson, 1970) This is reflected in the 
fact that the problems DESI has been exposed to are "problem set" problems, 
not the sort that a technician would encounter in daily practice. 

There is a large literature on the theory of design, artificial 
intelligence and design, and "computer-aided design." So far, however, the 
intersection of these fields is almost empty. Books about the design process 
(Alexander, 1964, Asimow, 1962, Buhl, 1962, Glegg, 1973) consist mainly of 
advice for avoiding overlooking things in pondering problems and working out 
solutions. About proposing solutions to start with, most of these authors say 
things like this: 

"Uhat enables us to draw from the warehouse of our experience just the 
right set of elements, and to put them into just the right combination so 
that they have a sense of fitting the situation, ue do not know, since no 
definite solution exists." (Asimow, 1962, p. 45.) 

This author is certainly correct that we do not know; programs like DESI are 

only tiny steps toward a theory of creativity. Of course, as a working 

hypothesis, we take issue with the claim that no solution exists. 

Design has attracted artificial-intelligence researchers, particularly at 

Carnegie-MeI I on University, for some t ime. Broadly speaking, areas l ike 

automatic programming, and, indeed, all problem solving, fall under the 
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heading of design. However, the theory of design narrowly construed has 
been - explored by workers like Grason (1970), who studied resolution of 
constraints on floor plans; Eastman (19G8), who did a formal pychological 
study of performance on the task of redesigning a bathroom; Haney (13681, who 
studied the automatic design of computer instruction sets; and Latombe (1976). 
whose rule-based design system is an interesting alternative to mine. I have 
found especially useful the theory paper by Freeman and Newell (1969) on a 
general theory of design, from which I have borrowed heavily. (See Chapter 
III.) 

One might expect the field of "computer-aided design" (CAO) (Vlietstra and 
Wielinga, 1973, Kuo and Hagnuson, 1969, Furman, 1970, Rosenbrock, 1974) to 
have produced many expert programs for a general AI program to compete with. 
This is not yet the case; "CAD" usually has little to do with the automation 
of the actual design process, but concerns itself with graphics packages, 
analysis programs, and other interactive aids to it. For example, one author 
distinguishes "three modes of [computer] operation: 

(i) Analysis. An engineering situation is specified in full 
mathematical detail by the designer, and the computer draws certain 
further mathematical consequences.... 

(ii) Synthesis. The designer specifies in detail the properties which 
his system must have, to the point where there is only one possible 
solution. The computer finds this solution. An example is optimal 
control. 

(iii) Design. This is the creative act of a designer, guided by 
calculations on the computer and interacting with them in a sequential 
manner to produce a satisfactory solution." (Rosenbrock, 1974, p. 29) 

The electronics synthesis tasks to which computers have been put include very 

low-level operations such as printed-circuit layout (e.g., Fletcher, 1974) and 

filter design (e.g., Chohan and Fidler, 1974). The approaches taken by most 

people in this field are usually very "mathematical," and concentrate on 

techniques for discrete or continuous optimization. For example, one approach 
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to circuit design in the literature (Director, 1974) consists of putting in as 
many components as one deems plausible and letting the program find the 
optimal component values for the task given. Many of these components will 
assume null values and "vanish"; thus this approach starts with a big circuit 
and finds the subset that does the job! 

CAD is only beginning to become aware of non-numerical techniques. (But 
see Powers, 1973.) DESI relies almost entirely on non-numerical techniques, 
and is very poor at constraint resolution and component-value optimization. A 
practical system would have to combine the tuo approaches. 

It is impossible to survey this field in detail here. It includes its own 
journal, Computer Aided Design, and supports periodic conferences. 
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II Expressing Knowledge In NASL 

The heart of DESI is the NASL interpreter, and the STP theorem prover 
which it drives. The theorem prover gives the system a general and flexible 
notation; the interpreter imposes an innate interpretation on some of the 
expressions of this notation. In this Chapter, I will give a discursive 
introduction and overview of the interpreter, describing STP and other 
inferential protocols as they come up. (See Fig. 1.9.) 

The NASL interpreter is a problem solver of the "problem reduction" type. 
(Nilsson, 1971) That is, it solves problems by reducing them to simpler 
subproblems. The differences between this structure and a programming 
language are: that a problem solver must decide upon the order in which to 
attack subproblems; that a problem solver often has subproblems of the form 
reduce problem so-and-so," where a programming language has only the 

subroutine call; and that a problem solver must occasionally choose between 
alternative approaches. 

The designer of a problem solver must confront the problem of search. For 
problem-reduction problem solvers, this classically takes the form of a search 
through an AND/OR graph of possible approaches. (Nilsson, 1971, Fahlman, 1973, 
McDermott, 1974a) Whether the search strategy is depth-first or more clever, 
it depends upon being able to save and restore states of the problem solution 
and hence of the "world model"; • this has recently tended to be implemented 
using a "context" mechanism. (Sussman and McDermott, 1972) 

I believe that searching uill always be a part of Artificial Intelligence 
technique. However, it seems to me that search among alternative sequences of 
subproblems and world models is a mistake. My principal reason for this 
belief is the observation that in the normal course of human problem solving, 
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a rather different faculty is used more heavily, namely, the ability to 
correct one’s errors. The difference between these alternatives is this: if a 
"■state of the world" is thought of as an internal data structure, completely 
known and under control, it is just as easy or easier to return to an earlier 
state to try something else as it is to generate a new one. But if states of 
the world are really states of the whole world, about which one’s information 
is limited and his control slight, quite the opposite is the case. 

So the question, for electronic circuit design, is whether the unfolding 
circuit model is to be thought of as an internal data structure or as a 
diagram on a piece of paper. A little reflection on this choice has drawn me 
to the second alternative. Since useful plans will ultimately have to be 
applied to the real world, whose surprises will always cause mistakes and 
revision, the problem of correcting errors rather than "popping them off the 
context tree" will have to be faced eventually. There is no point in 
perfecting a plan down to the last detail if circumstances will wreck it. 

This is probably why people worry so little about producing optimal plans. 

If search isn’t through states of the world model, but it is necessary, 
what is it that is searched? I think it is knowledge about courses or action. 
People can correct states of the world created by the wrong plan, but they 
don’t normally do this as a way of stumbling on the right plan. Instead, they 
use know I edge Iike 

"Under circumstances ..., plan ... will work." 

"If .... don’t do ...." 

Consider the difference between human and machine playing of chess. I 
will assume the reader is familiar with the usual program organization around 
the idea of minimax tree search. (Slagle, 1971) A human, by contrast, learns 
to play. His initial plan is simply to make a legal move, wait for his 
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opponent’s reply, and repeat this until the opponent wins. As time goes by, 
and he sees and hears more and more about the game, where does he put what he 
learns? According to the theory I am presenting, it becomes part of the 
advice surrounding the "make a move" step. This advice is usually in terms of 
board patterns, phases of the game, etc. Eventually, more sophisticated 
advice in terms of anticipating possible opponent replies is assimilated. If 
the deductive system for manipulating this advice is adequate, simple tree 
searches will appear as a trace of its manipulations. But this will never be 
assimilated to the overall planning level. The planning level does not become 
nondeterministic. Instead, what begin to appear there as the player becomes 
more confident of his powers are "game plans," long-term strategies which 
influence his choice of moves. 

This sort of search through knowledge about alternative courses of action 
is worth spending a lot of effort on. It has three loci in the NASL system. 
The principal one is the theorem prover STP. (Sect. II.B.2) This is 
supplemented by "choice Inrormatlon." (Sect. II.C.l) If all else fails, the 
system calls itself recursively to " rephrase " an action. (Sect. II.C.2) I 
have worked hard to make these devices sophisticated. I have given less 
thought to the problem of undoing mistakes (Sect II.E), and none to the 
question of learning search knowledge. 

Because deductions about courses of action are so central to the theory, 
NASL must be a language for describing problems, plans, and physics. The 
categories it uses for descriptions, and the inference algorithm it can call 
upon to manipulate them, determine its abilities and limitations. The 
limitations are in some ways as important as the abilities. The fewer ways 
there are to express something, the more likely it is that the formulas 
related to it will be noticed during rule application, and the more flexible 
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and extensible the system will be. Conversely, to the degree that each user 
is forced to make up his own control conventions, the less likely it will be 
that information from one user will ever affect the system’s approach to 
problems posed by another. 

NASL is not a typical programming language, since the user can intermix 
fragments of plans and axioms governing the physics of problem domains with 
fully developed programs. On the other hand, it bears a stronger family 
resemblance to programming languages than to anything else, so I have included 
a "programmer’s guide" at the end of this chapter for those interested in 
programming in NASL. 

II.A The Natural History of Actions 

The fundamental concept implemented by the NASL interpreter is the concept 
of task. A task is an activity to which the interpreter is committed. The 
basic drive of the interpreter is to accomplish all the pending tasks. 

Examples of tasks from several domains are, 

"Put Block A on Block B." 

"Wait here for five minutes." 

"Put the male chicks in this box, the females in that one." 

"Win the war, and keep the peasants happy." 

"Think of a fallible Irishman." 

"Keep your promises." 

"Convince yourself that all equilateral triangles are isosceles." 

In electronic design, tasks range from wiring two objects together, to 
designing a hi-fi system, to finding a resistance that satisfies a constraint. 

The reason for the broad definition is my goal that as much a9 possible of 
what the interpreter is doing should be explicit, so that reasoning about it 
can be shallow. For the same reason, it will be important that control 
information be expressed in a notation compatible with everything else. So I 
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represent tasks as NASL formulas of the form 

. t/: TASK |name| < -input pvars- > 

IX ( -varg- ) |action| ) 

< -output pvars- >] 

Unfortunately, I must pause here to describe the notation, both object and 
meta. NASL formulas are always enclosed by [brackets]. Uhen I am describing 
a formula, I enclose syntactic variables in brackets like this: or 

like this: The second kind indicates that a sequence of syntactic 

constructs is wanted. So, for example, an instance of a task might be of the 
form 

[/:TASK (COUPLER PLAN071) <’(BUFFER072) ’(AdP#73)> 

(X (STAGE1 STAGE2) (COUPLE 7STAGE2 7STAGE1) ) 

<’(CKT074)>J 

This describes a task, named (COUPLER PLAN#71I, which requires taking the two 
circuits [(Af1P#73)] and ((BUFFERS)] and COUPLing them to make something 
which will be called t(CKT#74)]. (Notice that the NASL notation permits 
tuples of objects delimited by <angle brackets:-, and X-expressions to express 
functions and predicates.) /:TASK is a predicate of four arguments. It 
begins with the prefix "/:" which indicates that it is a built-in predicate 
used by the interpreter in some way. A complete catalogue of built-in 
predicates and functions appears in Appendix 1. 

The word "pvars," for "plan variables." refers to terms, such as 
[(BUFFER072)] and t(CKT#74)], uhich are set equal to calculated quantities in 
the course of executing tasks. They acquire values by appearing in "reurite 
rules" of the form 

(-/> *|term| |value|] 

(Cf. (Bledsoe and Tyson, 1975), where they are called "reduction rules.") In 
my example, if [-/> *(BUFFER072) DEV075) and (-/> ’ (AMP073) DEV#7GI appear in 
the data base before execution of the task (COUPLER PLAN#71I, DEV#76 and 
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DEV#75 might be coupled to produce QEV#77; then the interpreter would add t-/> 
MCKT074) DEV#77I to the data base. (For an explanation of the single quotes, 
see Appendix 1 or Sect. 11.8.2.) In defining actions like COUPLE, I will 
indicate their outputs with the symbol "■■>" thus: 

[COUPLE |ckt 1| |ckt 2|3 --> <|new ckt|> 
to show what new value formulas they leave in the data base. 

Anyone familiar with the AI languages (Bobrow and Raphael, 1974, Hewitt, 
1972) will recognize the concept of "present in the data base." In NASL, 
there is always a current "data pool" for formulas to reside in. Formulas 
found there are supposed to be true; those absent have unknown truth values. 
(See Sect. II.B. The phrase "data pool" is meant to supersede the misleading 
word "context." (McDermott and Sussman, 1973, Rulifson et. al ., 1972)) 

This notion of task already embodies a complexity not found in the action 
languages of Sacerdoti (1975) and others (Sussman, 1975), namely, that tasks 
will not be fully specified until their input pvars are known, and that tasks 
can compute values to be used by subsequent actions. It will be seen that 
this broadens the scope of the action system considerably, while making future 
actions harder to analyze. It seems essential for automating design. 

With just this much machinery, plus a simple forward deduction scheme, we 
have a notation similar to that of a production system (Newell, 1973a, 
Rychener, 1976). For example, we might have a deductive rule that says 

t(DEV-TYPE ?A COMMON-EMITTER) 
d 3B(/:TASK ?B <> (X 0 (BIAS ?A)) <>)), 

meaning, "Every common-emitter amplifier must be biased." (I have introduced 

standard logical notation for implication and quantifiers. (Suppes, 1957) 

Variables are prefixed by free variables are supposed to be universally 

quantified. The internal notation for implication will be explained below.) 
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This rule is analogous to a production in having a condition on the left and 
an action on the right, but it differs in certain crucial ways. 

First, we are not limited to condition-action pairs. The more basic case 
is condition-condition." This enables us to treat deductive information 
retrieval as a process distinguishable from plan execution. It can be 
optimized separately, using techniques specific to the kind of search that 
arises during deduction. (Moore, 1975, Fahlman, 1975b) More important, since 
the system knows when it is doing deduction, and when action, it can keep more 
revealing records for use in choosing courses of action, explaining what it 
did, and recovery from errors. (In the future, such records could be used for 
careful assimi lat ion of new, possibly unrel iable, information. Cf. (Davis, 
197G, McDermott, B974a). By contrast, since the meaning of a condition-action 
pair depends entirely on the meanings (some deductive, some not) given to 
symbols by the behavior of the rest of the system as a whole, it is impossible 
to say whether a new rule of this kind is "correct" without extra commentary.) 

Second, deducing /sTASKS before executing them gives an extra layer of 
carefulness to the system. (Cf. (Sussman, 1975), where the term "careful 
mode is introduced.) A task is always noted in the current data pool before 
being executed. Here it can trigger other tasks or be available for other 
deductions. Furthermore, the system can note a task some time in advance of 
when it actual ly decides to do it. For example, a task can appear before its 
pvars values are known. More generally, a formula of the form 

[/:SUCCESSOR |task name 1| |task name 2|J 
must mean that task 2 is to be postponed until task 1 has been "begun" (in a 
sense explained below). In this way, a netuork of tasks linked by /:SUCCESSOR 
relations and variable flows is created (which the interpreter will munch 
"from left to right"; cf. Fig. II.1). 
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★acquire speaker Q 
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connect them 


^ verify that the 
Kj assembly works 
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bias it 


★enabled tasks 


Figure 11.1 A Task Net, or "Plan" 

Finally, a typical production-system action i9 always a primitive that can 
be carried out immediately, while some NASL tasks require mu9t be broken down 
into subtasks in order to be executed. This requirement is what makes NASL a 
problem solver. In other words, a task can be as much a part of the problem 
as of the solution; it looks like part of the solution to its superiors, and 
part of the problem to its subtasks. 

* Thus, a task (or action) is either primitive or problematic. An action 
may be primitive in two ways. It can have a LISP program for carrying it out, 
or it can have a set of model manipulation statements that hold true of it. 
These statements are the same a9 STRIPS’s add- and delete-l i9ts. (Fikes and 
.Nilsson, 1971) They are sufficient to represent completely only the simplest 
of actions, but they make these actions easy to reason about. (Cf. Sacerdoti, 
1975). 

A problematic task must be "reduced" to one or more subtasks. This 
relation between tasks is expressed by formulas of the following sort: 

I/sSUBTASK |subtask name| Isupertask name|] 

A task can be the subtask of more than one super task. 
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Task reduction can occur in more than one uay. The deductive system can 
infer a complete set of subtasks of a task in the course of foruard deduction. 
However, this fai Is to give enough direction or power to the problem-reduction 
process. As described in Section II.B, the interpreter must have the concept 
of one action being a uay of carrying out another, expressed like this: 

t/:T0-D0 |task name| |action| < -output pvars- > |method|I. 

This is intended to mean that the method is an effective, feasible, and 
permitted uay of accomplishing the task consisting of the action. Such 
statements can be used in the creation of subtasks. 

The method' to uhich a task is reduced may consist of a single action, or 
it may be a "macro action" uhich stands for an entire subnet of neu tasks. 

This requires the notion of a plan schema, an abstract object. Instances of 
uhich may be thought of a3 hanging as little subnets off nodes in the task 
network. (Fig. 11.2) The manipulation of instances of these schemata is 
described in Sect. II.B.1.2.1. 


n 
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Figure 11.2 Task Network with Subnets 
Thus tasks may be classified according to whether their actions are 
primitive or problematic. These classifications form one of the taxonomies 
shown in Fig. 11.3. 
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Problematicity 

Primitive 

Model manipulator 
Macro 

Primitive policy 
Problematic 


Honastlclsm 

Inferential 
UorIdly 

Parasitism 

Primary 

Secondary 

Figure 11.3 Logical Taxonomies of Tasks 
The other two taxonomic classifications are independent of this one. One 
classifies tasks according to "monasticism." Every task is either 
Inferential, in which case it consists of inferring formulas from other 
formulas supposed to be true; or "worldly," when it or some of its subtask 3 
perform model manipulations. This classification is expressed by means of the 
predicate /:INFERENTIAL. 

The last taxonomy is the important classification by "parasitism." A task 
is either primary, meaning that it has steps to be pursued in order; or 
secondary, meaning that its "execution" amounts to influencing or monitoring 
the execution of primary tasks. Ongoing secondary tasks are somewhat 
grandiosely called "policies," How they are handled is described in Sect. 

II.B. Some representative classes of policies, expressed in English, are 

"Uait untiI ... is true." 

"Notice if formula ... is removed." 

Take into account desired feature ... of the device you are 
designing." 

"Constrain quantities ... to satisfy ..." 


u 
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Policies, like primary tasks, may be primitive or problematic, worldly or 
inferential. 

A policy may have a scope, which is the primary task whose execution (or 
whose subtasks’ execution) it is intended to influence. As you might expect, 
this is indicated thus: 

[/:SCOPE (secondary task name| Iprimary task name|) 

Policies do not outlive their scopes. In drawing task networks, I will put a 
little cloud around a task to indicate that it is the scope of one or more 
policies; the policies will be tied to these clouds with a line. (Cf. Figs. 
III. 7 and 111.8.) 

There is no mystery to the notion of policy. All computer programs embody 
policies; the particular data-base and interrupt mechanisms I use to implement 
them are commonplace in AI applications. The novelty is that the notion has 
been made explicit, and, in a modest sense, put into the logical calculus. 

This prevents two problems with the usual use of the implementation 
mechanisms. First, typical Al-language "demons" (Charniak, 1972) fire off in 
the middle of primitive data-base operations and get complete control of 
operations. Without conventions, it is difficult for other processes to know 
uhat the intentions of these little monsters are. 

Second, policies are to be used to express things like "loop invariants" 
and "program assertions" (Floyd, 1967), which are usually extraneous to actual 
program text and only indirectly related to individual program steps. But a 
problem solver has need of the notion of a "partially-reduced" problem, some 
of whose subtasks have not been fully reduced to primitives. This is 
difficult to capture without the concept of a policy. For example, consider a 
program to count the prime numbers in a table. The text of the program 
contains instructions to initialize a counting variable and increment it just 
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after a prime number has been discovered. The purpose of this variable may be 
expressed by an invariant of the form "x is the number of primes in the part 
of the table already looked at." Uhat I am trying to capture is the notion of 
an early, unfinished version of the program, in which the pieces of text do 
not yet exist, and the invariant is all there is. 

A plan is, in a sense, this kind of unfinished program, with the 
difference that it gets executed without ever getting completely written. 
Comments on a plan are not there to explain an existing text or to help prove 
that it uorks; they are there to explain an ongoing course of action, and they 
must be executable. Their individual steps may indeed involve initializing 
and incrementing counters; these will become subtasks of the policy. 

I will conclude this section by listing some limitations of this plan 
calculus. These fall into two categories; bad limitations and good 
Iimitat ions. 

The bad limitations are those due to the fact that I knew the plan 
language was going to be used for designing and I didn’t have the time to 
implement unnecessary features. So I didn’t put in features such as other 
agents’ plans, or notions like "prerequisite of an action." These and other 
inadequacies are described at slightly greater length in Chapter VI. 

The good limitations are those arising from these goals: 

(1) Deductions about plans ought to be simple and shallou. 

(2) New knowledge must be expressed in a notation compatible with old. 

By deductions about plans, I mean deductions about current plans, not "proofs 
of plan properties. (Cf. Sect. VI.C) It ought to be easy to deduce uhat you 
are doing. Otherwise, the executions of subplans cannot interact, and the 
not' 00 of policy will be meaningless. The second requirement is related to 
our desire for flexibility. New knowledge is worthless unless it is expressed 
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in a familiar language. There should be just one obvious way to express any 
given piece of control information. (Keep this in mind as I expand on the set 
of control concepts in the following sections.) 

An example of a good limitation is that no loops and conditionals are 
allowed in the language. That is, all iteration and testing is done in the 
deducer. There are no gotos in the system. There are instead much higher- 
level concepts like "choosing." It remains to be seen whether 1 have been 
successful in inventing transparent but powerful control ideas. (I should 
mention that recursion is not forbidden in the system; a plan-schema instance 
can have subtasks derived from an instance of the same schema. It probably 
should be forbidden, in this general form; 1 use it sparingly.) 

1I.B Interpretation and Inference 

One thing to do with the predicates I introduced in the last section is to 
put them in axioms and prove things with them. For example, many of the 
electronics and design facts in Appendices 2 and 3 have conclusions of the 
form t/:TASK ...], meaning, "I should be doing ...." Clearly, a system which 
just proved things of this sort without acting on them would be a perfect 
catatonic. Its deductions would occur in a void. Their full meaning depends 
on there being an "action system" which interprets the result of such 
deductions as commands to act. I will call formulas like this which directly 
influence action pragmatic formulas ; the characteristic functions of these 
formulas are pragmatic functions or, more specifically, pragmatic predicates. 

I have already observed the convention that the names of such functions and 
predicates always start with to emphasize that their meanings depend 

mostly on the action system. In this section I will introduce more of them. 



II Expressing Knowledge in NA5L 


57 


(A complete catalog appears in Appendix 1.) All predicates not directly 
influencing action mean, in some sense, only what the axioms they appear in 
say they mean. 

In this section I describe the operation of the interpreter and the 
theorem prover it uses, called STP. 

II.B.l The NASL Interpreter 

The outer loop of the interpreter is to 

Pick a task to uork on; 

If it is primitive, 

Execute it or elaborate it; 

Otherwise, find a way to work on it {"reduce" it); 

Repeat until there are no more tasks 

The first step of the interpreter cycle, "picking a task," is done by a 
system of forward deduction of /:SUCCESSOR relations. The axioms that support 
these deductions are the user’s responsibility. The system chooses at random 
from the tasks that it is logically permitted to do next. 

Much of the uork is in the second arm of the conditional. The existence 
of this step is what makes NASL a problem-reduction problem solver instead of 
a programming-language interpreter. Reducing a task involves a call to the 
theorem prover STP and some more powerful mechanisms. (Sect. II.C) 

II.B.1.1 Selecting a Task to Uork On 

The NASL interpreter interleaves planning and execution of plans. (Cf. 
(Nilsson, 1973).) Different tasks are in different states, which change as 
time passes. The current state of a task is composed of its task-status, its 
enablement status, and, for problematic tasks, whether it is reduced. (Fig. 
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11.4) Uhen a task is created, its state is PENDING and BLOCKED. When a 
PENDING task is ready to be executed, it becomes ENABLEO. Uhi le it is being 
Morked on, it is ACTIVE. Uhen the interpreter is through with it, it is 
FINISHED. The status of a task is expressed in a formula of the form 
t* , /> ’ I/s TASK-STATUS | task name|) |status|) 
where status is one of the three states I gave. 


PENDING 

ACTIVE 

FINISHED 

BLOCKED ENABLED 

SUBS-ENABLED 

SUCCS-ENABLED 


un-REDUCED | REDUCED | 

-► time 

Figure 11.4 Life History of a Task 

Meanwhile, as a task evolves, its enablement status changes to "gate" its 
subtasks and successor tasks. Recall from Sect. II.A that the order of 
execution of tasks is constrained by /{SUCCESSOR relations. In addition, 
subtasks of a task may be deduced before the task itself becomes active; the 
subtasks must be postponed. So there are three facts that must be true before 
a task can be enabled: all its super-tasks must be ACTIVE; all of its input 
pvars must be known; and all of its predecessors mu 9 t have enablement status 
"successors enabled." (Fig. II.4) Uhen a task is FINISHED, its successors 
are always enabled, but the system must be flexible enough to allow execution 
of successors to begin before this. For this reason, I introduce the 
independent concept of enablement status, 

[«*/> ’ (/:ENAB-STATUS | task name|) |status|), 
where status is BLOCKED, ENABLEO, SUBS-ENABLED, or SUCCS-ENABLED. These flags 
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are synchronized with the ordinary task-status as shown in Fig. 11.4. As a 
task- becomes active, the system checks its subtasks, and enables all those 
with no other impediments; similarly, when the task enters SUCCS-ENABLED mode, 
the system checks its successors. (It should be clear that if a task has two 
predecessors or super-tasks or some combination, all must be in the proper 
state.) 

A useful service provided by the system is that as soon as all the input 
pvars of a task are known, whether or not there are other gating conditions 
remaining unsatisfied, a formula of the form 

[/:TASK-ACTION |task name| |action|] 
is recorded in the data base. 

Figure 11.4 also shows the transition of a problematic task from being 
"unreduced” to being "reduced." Uhen a task has been completely replaced by 
subtasks, the proposition 

I/jREOUCED |task name|) 

is supposed to hold true of it. The system will not bother to reduce a task 
if such a formula has already been deduced; this enables task netuorks to be 
built up entirely by forward deduction. 

11.6.1.2 Executing Tasks 

Uhen a task has been selected, it must be executed. If its action '13 of 
the form t|f| ...], I call F its action function. The system can tell by 
looking in the data base or on the property list of f whether the task is 
primitive or problematic. If it is problematic, it must be reduced. 


II 
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II.B.1.2.1 Primitive and Problematic Tasks 

An action can be primitive in one of tuo ways: its action function can 
have a defining LISP function on its property list, or it can be defined by 
mode I-manipulation axioms. The latter are looked for first. 

The interpreter calls STP to deduce formulas of the form 

[/:MOO-flAMIP |task name| |action| 7DELETELIST 7ADDL1STJ, 
uhere the variables 7DELETELIST and 7ADDUST are intended to become bound to 
tuples of "senses," or quoted facts. (See Appendix 1.) For example, we might 
have 

[(ON ?X ?B) 3 

(/jMOD-MANIP 7TASK (HOVE ?X ?A) <’(ON ?X ?B)> <’ (ON ?X ?A)>)I 
in the BLOCKS world. The meanings of the addlist and deletelist are the 
traditional ones. (Fikes and Nilsson, 1971) The model (data pool) is to be 
updated in the obvious way: the formulas represented by the elements of the 
deletelist are deleted, and those represented by the addlist are added. These 
manipulations are called model effects. 

If the primitive has a defining LISP function on its property list, that 
function will just be executed. It can do something, return a value, 
establish a policy, or annex a subnet. An example of the first kind is the 
action [GRABBA |property|) in the design world, which creates an object with 
the property. Values are returned by deductive actions like /:FIND, which 
call STP to retrieve data. 

The most important kind of primitive is the "macro," which annexes a 
subnet. The typical member of this class is 

[/:D0-SUBNET |plan schema| |vars-map|l. 
which is used to instantiate plan schemata and hang them off the net. 
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In the current implementation of NASL, plan schemata are not represented 
as identifiable objects. Instead, they are defined implicitly through 
statements of the form 

[(/:PLAN-INSTANCE ?NAf1E |plan schema| 7SUPER-TASK) 

D (AND {/:TASK |subtask 1| ...) 

(/:TASK jsubtask 2| ...I 
• • • 

(/.•SUBTASK |subtask 1| 7SUPER-TASK) 

(/.•SUCCESSOR |subtask 1| |subtask 2|) 

-other connectivity relations-)] 

by which nets of subtasks are created and linked together. Executing /:D0- 
SUBNET creates a new plan instance and records 

[/:PLAN-INSTANCE |plan instance name| |plan schema| |super task|]. 

This will trigger the forward deduction of subtasks in the schema. 

These subtasks will compute and use the values of plan variables 
("pvars"), some of which the super-task network needs; the vars-map argument 
of /sDO-SUBNET tells how to map the schema’s variable back to the calling 
plan. To make this work, all the pvars used by the tasks in the schema must 
be of the form E(|var name| |plan instance name|)]. (For an example of the 
use of /sDO-SUBNET, see the formulas +0ESI-1 and +0ESI-2 in Appendix 2.) 

A macro-expanded task will be FINISHED when all its subtasks are. It will 
have enablement status SUCCS-ENABLED when all of its "main" subtasks are 
FINISHEO. This device is intended to capture the idea of a task reducing to 
two kinds of subproblem: things which must be done before going on to the 
successors of the task, and things which can wait. An example is biasing one 
stage of a complex circuit (see Appendix 3); this will appear as a subtask of 
acquiring a circuit, but it should not be done when the circuit is first 
obtained; instead, it may become a successor of, e.g., coupling the circuit 
to something else. Subtasks labeled /sflAIN are those whose completion is a 
necessary condition for enabling a supertask’s successors. (See Fig. II.5.) 


n 
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Figure 11.5 Enablement Relations in Subnets 
This is one of the ways in which the subtask relation differs from the 
usual relation between a program step and its program. 

Other macro actions are described in Appendix 1. 

This concludes my description of the execution of macros and other 
primitives. All other tasks have "problematic" actions. In such a case, NASL 
calls STP with the request 

[/: TO-DO |task name| |action| < -output vars- > 7UAVI 
If STP returns exactly one value for ?UAY, a new task for the new action is 
created, enabled, and made the /:P!AIN subtask of the current task (which 
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becomes /sREDUCED). If STP does not return exactly one value, special things 
must'occur uhich are the topic of Sect. II.C. 

11.B. 1.2.2 Primary and Secondary Tasks 

Primary tasks are those which do something or infer something. Primitive 
primary tasks are those defined by /:M0D-MANIP and inferential functions. 
Secondary tasks (" polIcles") are those uhich influence the execution of 
primary tasks. 

The principal primitive policy is 

[/:MONITOR |formula| (* (|v|) |action|)}, 
which does nothing unless some task removes the formula as a model effect. 
Then a new subtask will be created with the given action, with v bound to the 
task that did the removal. This is used to implement protection. 

Policies may cause the "intermittent" execution of primary actions. A 
task with action I/:CONTINUE Ipolicy task) |action|) will be executed in a 
nonstandard way. It causes a deduction of the form 

1/:TO-CONTINUE (policy task| |action| <> ?UAY) 
and the resulting sub-action is attached to the original policy task node of 
the task network. (See the implementation of protection described in Chapter 
III.) Thus a policy may occasionally cause execution of real actions in the 
process of executing /:CONTINUES. 

A problematic task may also be primary or secondary. This is not 
determined when the task is reduced, but after its /:MAIN subtasks have been 
set up. At that time, if any of its subtasks are discovered to be secondary, 
and to have a scope larger than it, it is declared to be a policy. 

The main difference between the execution of primary and secondary tasks 
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is in how they are finished. A secondary primitive will not be finished until 
the task which is its scope is finished; then the interpreter executes 
t/;FINISH |poI icy11 to clean it up. Problematic tasks of both kinds are 
finished when all their 9ubtasks are. 

Here is a summary of the ways in which policies influence primary actions: 

(1) The primitive policy /snONITOR is used to implement things like 
"protection." (Sussman, 1975) 

(2) The presence of formulas regarding the status of a task can license 
deductions of various sorts. The conclusions can be of the form I/:TASK ...1 
and I/:TQ-D0 ...1, for example, and thus trigger things to do and ways of 
doing them. 

(3) In particular, policies often influence the "choice protocol 
described in the next section. 

(4) The use of /sCONTINUE can cause intermittent execution of primary 
actions. 

When policy-specifying formulas influence the interpreter s deductions, it 
will record their influence in the form of /:SUBTASK assertions. That is, 
when /:TASK formulas are deduced from policy task formulas, they become 
eubtasks of those policies. (Sect. II.0) Thus, a natural structure evolves 
In which a task can be a subtask of "make a filter" (primary) and "keep the 
cost down" (secondary). 

II.B.2 STP — The Stupid Theorem Prover 

STP is a backward-chaining, pattern-matching theorem prover. In R. 

Moore’s (1975) phrase, it is a procedural deductive system. Such a system may 
best be thought of as a descendant of PLANNER (Hewitt, 1972) which emphasizes 
its logical aspects instead of emphasizing its programming-Ianguage features 
as most other descendants have done. By this I mean that it manipulates, not 
arbitrary list structures, but formulas that are supposed to represent 
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statements about entities. There are no side effects during deduction; the 
act'on system is completely divorced from the operation of the theorem prover. 

This means that the theorem prover can be optimized in various special ways. 
(See Appendix 4.) 

STP is used by the system for two kinds of deductions; those about tasks 
and actions and those about the physics of the problem domain. 

STP is not particularly bright; it is to be used for information 
retrieval, and it tends to balk at intricate reasoning. More sophisticated 
reasoning is done as inferential tasks. (There are things to regret about 
this organization. See Sect. VI.B.) Some kinds of reasoning do not naturally 
fit into the theorem-proving paradigm at all. These will be discussed in 
Sect. II.C. 

Actually, "theorem prover" is a very misleading term. The "theorems" such 
programs prove would not be recognizable to a mathematician; the way in which 
they go about it would be even more incomprehensible. Nonetheless, I wi I I 
continue to use this term, since by now AI people are unlikely to read 
anything very pretentious into it. 

A theorem prover may be thought of as a problem-oriented interface between 
a problem solver and bare data-base machinery, such as that described in 
(McDermott, 1975). For example, an AI data-base manager implements the notion 
of "data pool." This will be used to implement the higher-level notions of 
"packet" and "reference point." (See below.) The calculations involved can be 
made invisible to the user, who thinks in the higher-1 eve I terms. 

The basic data-base operations are three; putting things in, taking things 
out, and finding things. These are handled by the three primitive (LISP) 
operations RECORD, ERASE, and STP. RECORD puts a formula into a data pool. 

It also does forward deductions from that formula in a way to be described. 


n 
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The results of these deductions are recorded also, and conclusions are linked 
by "data dependencies" to the formulas which support them. (See Sect. II.D.) 
ERASE flushes a formula and everything it supports from a data pool. 

When proving theorems, STP works, like every other "theorem prover, by 
matching goal formulas against "knowledge" formulas, detaching the output, and 
repeating until a proof from atomic data is obtained. (Cf. (Bledsoe, 1975) 

For technical reasons (R. Moore, 1975), STP really attempts to refute the 
negations of goals. See Appendix 4.) 

Formulas are stored in the data base in clause form. Clauses are 

implications whose format tells how they are to be used. The two most common 

forms are 

t-/> C |p] |q|], meaning, "to prove Q, prove p" 

and [-/> A jpj jgj], meaning, "i f p is recorded, record q ." 

(These correspond in an obvious way to Planner’s consequent and antecedent 

theorems. (Hewitt, 1972, Moore, 1975)) The arguments p and q to these 

predicates can be clauses as well; my clauses have more pragmatic structure 

than those of a resolution theorem prover. (Robinson, 1965) 

Internally, these clauses are stored as (pragmatic) disjunctions of the 

form 

[/sCONSEQ | g| (NOT |p|)] 
and [/:ANTEC (NOT |p|) |g|] 

respectively. These forms are occasionally useful externally as well. 

A third pragmatic disjunction is /:GEN. I/:GEN |p| I<?13» when "recorded, 

really causes counterexamples to p to be found and, for each one found, an 

instance of q to be recorded. This may be also be expressed [-/> G (NOT |p|) 

|g|]. For example, recording 

[-/> G (DEV-TYPE ?X COMMON-EMITTER) 

(DEV-TYPE ?X AMPLIFIER)] 
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calls STP to find all common-emitters and record that they are amplifiers. In 
thi3- way backward deductions may be triggered in the midst of forward 
chaining. 

STP is oriented toward the task of information retrieval. When given a 

goat with free variables, it doesn’t interpret i t as a request to prove that 

objects exist which would satisfy the formula if substituted in; instead, it 

considers it a request to find and return these objects. This is like PLANNER 

(Hewitt, 1972) and QA3 (Green, 19G9a,b). (See Append! x 4.) 

For example, given the clauses 

(P A] 

(P BI 
[Q B] 

(-/> C (AND (P ?X) (Q ?X)) 

(R ?X)I 

and the goal; Refute [NOT (R ?Y)J, 

STP chains backward through the consequent clause to generate as subgoal 

Refute [NOT (AND (P ?Y) (Q ?Y))J. 

This becomes two "conjunctive goals"; "Refute [NOT (P ?Y)I" and "Refute [NOT 
(Q ?Y)]. STP finds Y -» A and Y -* B as answers to the first goal, and 
detaches [NOT (Q A)) and [NOT (Q B)] as alternative versions of the second. 

Only the latter of these succeeds. The returned answer is therefore Y -♦ B. 

The machinery to make this work reasonably well is described 
in Appendix 4. 

Some other interesting features of STP are these: 

(1) Ability to call LISP functions for low-level deductions. (Cf. 

(Nevins, 1974a,b).J I have made an effort to keep all such LISP-implemented 
concepts completely primitive and domain-independent. These are concepts for 
manipulating simple inequaiities, predicates on embedded formulas, etc. 

(2) "Non-monotonic" inference rules, which are implemented by having 


I 
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certain predicates be evaluated by calling STP recursively. For example, 

[/:CONSISTENTLY *|pattern|) will be handled by calling STP to see if pattern 
can be refuted. (The single quote is used to flag an expression within uhich 
substitution of equals for equals is forbidden; such an expression is called a 
"sense.") McCarthy’s "presumably" operator (McCarthy and Hayes, 1969) is 
defined as 

((PRESUMABLY ’?P ?USE) ■ (-/> ?USE (/:CONSISTENTLY *?P) ?P)) 
meaning, "if you can’t prove ?P is false, assume it’s true." Thus we have, (VX 
(BIRO ?X) o (PRESUMABLY (CAN ?X FLY) C)J, which means, "If X is a bird, then 
if you ever need to check if he can fly, assume he can if you can’t prove he 
can’t." (If the formula had had "G" instead of "C," the attempt to refute his 
ability to fly would be done at the time he was deduced to be a bird.) 

(3) Pragmatic handling of equality. The usual predicate-calculus notion 
of equality does not correspond very closely to the programming notion of 
evaluation. If you ask a theorem prover, "Find ?x such that 2+2 = ?x," it 
will tell you, "?x - 2+2," which is true but useless. An action module 
communicating with a deductive system must have the concept of "useful 
expression." In the midst of problem solving, some data structures are 
inherently more oriented toward getting on with things. Consequently, STP 
works closely with an evaluator (see Fig. 1.9), which applies rewriting rules 
found in the model to expressions. We have already seen these rules in action 
implementing pvars. They look like (*=/> ’(+2 2) 4). The "sense" quote is a 
way of forbidding applying the rules to subexpressions. (Otherwise, the rule 
would rewrite itself as (-/> 4 4).) 

The evaluator is used by the interpreter, by user plans which use the 
/tEVAL primitive, and by STP. (See Appendices 4 and 5.) Normal equality, 

(*■ 1 x| Iy|] , is used to express goals like, "prove two things are equal." 
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There is a "cheap" equality predicate called The only knowledge about 

it i-s [:• ?THING 7THINGJ. It is used in conjunctive subgoal 3 to "set" 
variables for future use. That is, the goal [:- ?X (F00 BAR)] succeeds, 
setting ?X to [F00 BAR]. The system will not waste its time trying to prove a 
goal like this if it doesn’t succeed immediately. 

When an equality is recorded in the course of trying to prove x and y 
unequal, the system makes an effort to translate it into a rewriting rule; 
otherwise, it will never interact with other deductions. Cf. (Bledsoe and 
Tyson, 1975). 

(4) Packets. 1 It often inconvenient to have to record a large 
conjunction as a consequence of some forward deduction. For example, in 
electronics, devices are of various types. If it is recorded that IDEV-TYPE 
DEV#73 COMMON-EMITTER], this might trigger the recording (via "-/> A") of 
scores of facts about DEV#73, most of which will never be looked at. This can 
be avoided by writing the relevant antecedent implication as 

(-/> A (DEV-TYPE ?CE COMMON-EMITTER) 

(/s PKT CE-PKT (?CE) 

I fact 1| 

I fact 2 j 
• • • 

I fact n|)]. 

As explained in (McDermott, 1975), defining this formula will create a packet 
which plays the role of the large conjunction with one free variable 
It is actually implemented as a "data pool layer" which can be added cheaply 
to the current data pool. The individual facts will be closed and indexed 
only as they are accessed. 

(5) A "modal" notation and inference mechanism. A general deductive 
system should be able to reason about hypothetical situations, other times, 
other creatures’ beliefs, etc. These concepts are in the domain of "modal" 
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logic (Hughes end Cressueii. 19721, a difficult study uith cany problems. I 
have implemented a modest system for doing some very simple modal deductions, 
which wees the “data pool" mechanism to implement "reference points." 
(Montague, 1974, Reseller and Urquhart, 1971) 

The basic modal notation in the NASL language is (T (reference point| 

| term|], uhich stands for the value of the term uith respect to the given 
eference point. In principle, these reference points could be other 
creatures minds, arbitrary points in time, or just "possible uorlds." Under 
this 5 ast interpretation, logical necessity might be taken to mean [VR (T ?R 
or "... is true in all possible uorlds." Houever. this uould require 
quantifying over reference points, a capability I have not had the time to 
pursue. Instead, DESI confines itself to the use of constant reference 
points. These are used (see Chapter IV) for things like the DC and 
sinusoidal-steady-state models of an electronic circuit. 

Th.s sort of mechanism is just a convenient notation for data pools (i. e ., 
"contexts") from uithin the logical language. To make it uork, I have 
introduced some notation for "frame" axioms. (Hayes, 1973a) A reference point 
is often defined in terms of the differences betueen itself and some set of 
super reference points from uhich it inherits most of its contents. These 
definitions are written thus: 

.0 bfamlld'Irur" ^ ,T ^ 

ToTlTLTZ: '1ST. ,3lse - The 9iven re,erencs p ° i " u 

((FRAME ?REF 7FRAHE-REFS) * 

(VP (3F (?F £ 7FRAME-REFS) a (T ?F ?P)) 

* (PRESUMABLY ’(T ?R P) C))J. 

conMruct;d i u,!ng’!hiTRAfirl«?oi n ‘p 1 ’ ,n ’ ,ead - 3 " eu d3ta p ° Bl iB 

superiors (be^a'p^eor r^d^'l [] ^ 93,3 P °°' h3 " 33 
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IN (reference point| J fact 13 means that the given fact is not inherited 
from the reference point’s frames. 

Formulas of the form IT (reference point| |fact|] are used in constructing 
neu reference points. Any such propositions lying around have their facts 
shoved into the neu data pool. 

Examples of the use of these formulas are given in Chapter IV. 

II.C Choice and Rephrasing 

As sketched so far, NASL resembles some more familiar problem solvers. 
Except for the imposed distinction betueen deduction and action, it is a lot 

I ike PLANNER. (Heuitt, 1972) The main difference i9 that it does no 

backtracking past model manipulations. Since it is more disciplined in many 
uays, it is better able to explain its actions. 

Houever, it suffers from some of the same problems as PLANNER-1 ike 
systems. In particular, a certain amount of the additivity I uanted uill not 
be found in this organization. Even though it is easy to add a neu plan 
schema to a body of facts, the interactions of this neu material uith the old 
are not so easily handled. 

For example, if acquiring a common-collector amplifier is knoun to be a 

good uay of achieving high input impedance, this fact might be lying around in 

a formula of the form 

["high input impedance required" 

3 (/jTO-DO ?T WAKE AMPLIFIER) <?N> 

WAKE COmON-COLLECTOR)) ]. 

(For a precise version of this, see Appendix 3.) Nou, say that the system is 
to be told about field-effect transistors (FETs). Since they have a high 
input impedance, an exactly similar fact uill be recorded regarding the FET 
common-source amp Iifier. 
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Now a request to make an amplifier will cause both these facts to be 
retrieved. What can be done? (We have already ruled out ju 9 t trying one 
until it fails.) One approach would be to force the user to revise one or 
both of the formulas to check for information that will distinguish between 
the tuo case9. However, this will lead to large, impenetrable implications. 
Furthermore, in some cases of such confusion, neither choice is preferred, but 
some synthesis of the two. We need a way to represent 9uch "differential 
diagnosis" and "partial-solution composition" knowledge in an additive manner. 

The solution is to face up to the necessity for treating "choice between 
alternatives" as a basic situation of problem solving, and to create new 
pragmatic predicates for handling it. This i9 the subject of Sect. 1I.C.1. 

The complementary problem that this brings to mind is when the deductive 
pattern-based backward chaining of STP is unable to retrieve any possible 
plans. This might be because there aren’t any, and the user must provide new 
information, but it also might be because the relevant retrieval strategy 
depends upon pattern-manipulation operations which are less disciplined than 
unification. For example, we might want to express, "If the problem mentions 
MHz, try special high-frequency heuristics." Here the traditional AI language 
solution is to allow arbitrary list-processing operations upon formulas. (The 
traditional predicate-calculus solution i9 to do aimless equality 
substitution.) Thus, in CONNIVER (McDermott and Sussman, 1973) a method with 
pattern (LAMBDA !>X !>Y) can match the calling pattern (LAMBDA (X) (F (G X))) 
and do anything it likes uith the pieces so generated. This is someuhat 
abhorrent, since it tends to destroy the notion that formulas mean anything. 
Who can rule on the consistency of a set of formulas that do things like that? 

My approach to this problem is to try to impose some discipline on this 
kind of manipulation. The idea is to signal explicitly when the system is 
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allowing itself to do things like that, and to impose restrictions on its 
behavior and the results it computes. This idea is developed into the 
"rephrasing" protocol of Sect. II.C.2. 

II.C.l The Choice Protocol 

Under some circumstances, STP is asked to return all the answers it can 
find (cf. Appendix 4), but it can be asked to return just one. In this 
situation, if more than one answer is found, the system performs a ritual 
invocation of information about choosing between them. This is called the 
choice protocol. For example, this protocol is called when DESI finds more 
than one possible circuit for a general concept like "amplifier." In that 
case, detailed information about the various types of amplifier interacts with 
information about what is required of this amplifier to force a choice. 

The first thing the chooser does is to create an (abstract) choice 
situation name and record in the data pool 

t/:CH0ICE |name| |context| |goal formula|I 
(The context is the inferential task for which more than one answer is found. 
In the case of the interpreter trying to deduce how to do something, this is 
just the symbol "EXEC.") For example, in trying to choose an amplifier, it 
would record 

[/:CHOICE C#535 EXEC 

t/sTO-DO TSK//437 (MAKE AMPLIFIER) <’(STAGE1 CKT#747)> 

?UAY]I 

The formal resemblance of this to /:TASK formulas is suggestive; we have in 
effect added a new kind of entity, the choice. The intent is that this 
formula will trigger forward deductions of the kinds to be described in a 
moment. The packet machinery of (McDermott, 1975) will allow the system to 
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bring in large packets of what may loosely be called "advice" appropriate to 
this situation. 

The use of "brackets inside brackets" is our first encounter with the 
concept of "embedded formula." (See Appendix 1). The system is treating the 
goal here as a data structure to be analyzed. 

For each of the possible answers, a formula of the form 

t/:OP 11 ON |choice name| |opt ion name| |answer formula|I 
is recorded in the data pool. For our amplifier example, we might have 
l/:OPTlON C#535 A#450 

[/sTO-DO TSK0437 (MAKE AMPLIFIER) <’(STAGE1 CKT#747)> 

(MAKE COMMON-COLLECTOR)] I 

[/{OPTION C0535 A0451 

[/{TO-DO TSK#437 (MAKE AMPLIFIER) <’(STAGE1 CKT#747)> 

(MAKE FET-COMMON-SOURCE))] 

Recording these formulas will trigger the deduction of formulas of the 

form 

[/{RULE-OUT |opt ion name|I, 

[/{RULE-IN |option name|], 

or [/{RULE-TOGETHER < -option names- > |neu answer formula)). 

The system first searches for conclusions of the form [/{RULE-OUT ...I. 
This is a call to STP, of course. If any are found, the options ruled out are 
removed from consideration. Next, the system looks for conclusions of the 
form [/{RULE-IN ...I. If any of these are found, the system throws away all 
options except those mentioned. Finally, it looks for /;RULE-TOGETHERs. If 
one of these occurs, the options it mentions are discarded in favor of the new 
answer formula. 

I f at any stage all options but one are eliminated, the protocol stops 
with a winner. If all the options are ruled out, the system enters an error 
protocol to show the user what it did and ask for corrections of its 
misinformation. If more than one option survives, the system records 
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[/:QUIESCENCE |choice name|J 
in an effort to trigger more forward deductions. 

The intent of these devices is clear. Differential diagnosis is to be 
performed by the first two kinds of formula, while /: RULE - TOGE THER s are 
intended to be one locus of composition of partial solutions in the NASL 
system. (The others are problem reduction (see above) and error correction 
(see Sect. III.O) in the context of patching electronic circuits.) The 
/:QUIESCENCE trick enables the user to encode advice of the form, "All other 
things being equal...," as a forward implication like 

(-/> A (/sQUIESCENCE ?C) ...J. 

The choice protocol keeps track of the rules which contribute to weeding 
out all but one option. These rules are used in building data dependencies 
(sect. II.D). In addition, when a policy is used in choosing a way to do 
something, the choice is made a subtask of that policy. For example, say 
there is a policy of the form "keep costs low," plus a deductive rule like, 

’’When trying to make a device, and trying to keep costs lou, then, all 
Other things being equal, if a circuit with inductors is competing as an 
option against a circuit without them, the one with inductors is ruled 
out. " 

Now if the task of constructing some circuit is elaborated into a device 
chosen on the basis of this rule, the task of acquiring the device is subtask 
of both the construction task and the costs policy. This leads to clear 
explanations by the system of its behavior. (Sect. V.A) 

(The choice protocol was inspired by the design of Marcus’s (1973, 1975) 
wait-and-see parser, which does similar things in choosing directions in 
which to parse.) 
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11.C.2 Rephrasing 

1 now turn to one of the most important and least elegant subsystems of 
NASL, the rephrasing protocol. This is the system which is invoked when STP 
is unable to find a reduction of a task. Rephrasing consists in treating the 
recalcitrant problem as an object to be transformed into a new problem. The 
pious hope is that the new one is easier. This, of course, is precisely the 
object of task reduction in the first place. So rephrasing may be thought of 
as taking extraordinary measures to reduce a task. 

The way this works is as follows. When the system is unable to find a way 

/sTO-DO something, a task 

[/•.TASK |name) <> . 

(X 0 (/:REPHRASE |task| |action formulal < -output pvars- >)) <>J 

is created, and made a predecessor of the losing task. This task is allowed 

to carry out arbitrary inferences in order to reduce the unreduceable task. 

For example, the design task DES#78, with action 

[DESIGN (X (X) (AND (IS AMPLIFIER ?X) 

(» (VOLTAGE-GAIN ?X) 100)) )J 

is unlikely to trigger an indexed solution. Instead, it must be rephrased as 
some set of simpler actions, by the use of electronics knowledge. So the task 

[/:TASK T0843 <> 

(X () (/sREPHRASE DES#78 

[DESIGN (X (X) (AND (IS AMPLIFIER ?X) 

(» (VOLTAGE-GAIN ?X) 100)) )1 

<|result pvar|>) ) 

<>] 

will be put in the task netuork as a predecessor of the design task. Its 
effect will be to reduce task DES#78. 

The rephrasing protocol must exist in order to provide for deductions 
beyond the scope of STP’s simple strategies. These fall into two categories, 
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one more elegant than the other. First, because it uses the interpreter, it 
can take advantage of the choice protocol, flexible planning and policy 
making, and even recursive rephrasing. Thus, for example, one can make finer 
choices than is allowed by just running the chooser on a set of possible 
reductions. 

Second, and less happily, the rephrasing protocol manipulates the action 
formula as an "embedded formula," and so is allowed to perform any operation 
on its representation. So one can write rephrasing plans which check to see 
if the given action refers to "UIDGETS" anywhere. In the next chapter, I will 
shou how, in the course of rephrasing design problems, A -expressions are 
routinely dismembered. This seems to be indispensable, but it would be nice 
if we could insist that the pieces be put back together in a legitimate way. 

This is a special case of the more general problem of making sure that the 
interpreter and inference mechanisms actually do what they are supposed to do. 
The difficulty is in specifying what the object of a task or protocol is. For 
choice, the object is fairly clears eliminate all but one option. (Inelegancy 
creeps in with /sRULE-TOGETHERS.) Elsewhere in the interpreter, I have 
ignored this very important problem, except for token checks such as that 
/sFINISH actually leave its task finished. In the case of rephrasing, the 
problem is especially acute; rephrasing can be thought of as a device for 
extending the pattern matcher by allowing arbitrary deductions about formulas. 
Something like this is necessary, but it should be better constrained. 

As it is, there are only a few restrictions on the use of rephrasing: all 
the actions undertaken as subtasks of a rephrasing must be inferential, not 
worldly; the rephrasing task must leave its target task /;REDUCED; and the 
subtasks resulting from a rephrasing must be syntactically legal (i.e., not 
contain Vs in funny positions or have any free variables, etc.). 


n 
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The rephrasing Knowledge for the design domain, which I present in the 
next chapter, is an example of what rephrasing ought to be. The formulas 
involved are reduced to pieces by one task, and parsed together again by 
others. I hope that this will prove to be an instance of some more general 
recognition strategy that is more constrained than what the system now allows. 

I have now described every module in Fig. 1.9. The search paradigm that I 
have developed may be summarized as: let the theorem prover search, but not 
too far or too deeply. All searches are intended to be short and sueet; the 
search is used for exactly those spots where there is no applicable knowledge. 
These short searches are organized by a plan interpreter, which decides what 
sort of knowledge is to be accessed. It can ask for answers to questions 
about how to do things, the physics of the domain, choosing among 
alternatives, or transforming its own problem statements. Thus, as far as the 
paradigm has been developed, it is in accordance with R. Moore’s (1975) 
observation that theorem provers are most naturally applicable to information 
retrieval problems, and that other control structures are needed for more 
sophisticated tasks. 

11 *0 Dependencies Among Data and Tasks 

•It is becoming generally realized that AI systems must record their 
reasons for their conclusions and actions. (McDermott, 1974a, Stallman and 
Sussman, 197G, Shortliffe, 197S) These records have many uses: 

(1) They can be used to explain reasoning and actions to a human user. 

(2) They guide the system in undoing faulty deductions. 

(3) They are a guide to correcting the effects of misguided actions. 

(4) They can be used in assigning the blame to incorrect rules. 

The basic relation among data is the deductive data dependency. 


M 
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(McDermott, 1975) Every time STP or RECORD does a deduction, it attaches such 
a dependency to the conclusion and the premisses; the latter become the 
supporters of the dependency, the former, the supportee. (See Appendix 4.) 
Ulhen the system doe3 an ERASE, all the supportees of the erased item are 
erased themselves if they have no remaining supporters. 

These support relations are accessible to the problem solver as a set of 
LISP-implemented predicates. In particular, 

(/:SUPPORT < -formula names- > |formula name|] 
is supposed to be true when the indicated dependency holds. 

These support dependencies are also created by the inferential action 
f' INFER (see Appendix 1). Other inferential tasks call STP and let it build 
dependencies. 

These devices account for the second in the list of uses of dependencies 
among data and tasks. The others are more complicated, because they involve 
the relation between action and the world model. Here are examples of the 
kinds of relations that can occur; 

(1) A task can have model effects. The relation between the task and its 
effects is non-deductive because erasing a task is not sufficient to undo its 
effects. (Besides, some of the effects are erasures.) 

(2) A task or pvar value can be based on choice information. Ue want to 
record this relation, but erasing the basis of a choice does not erase the 
choice, although it calls the wisdom of the choice into question. 

(3) Facts in the current model can support task statements. A fact about 
circuit topology supports a constraint on the physical quantities it 
influences. Erasing such a model-effect formulas should cause the task 
formulas to be erased too, 

(4) Facts in the current model can trigger tasks. This is a quite 
different situation from (3). NASL implements the common AI mechanism of 
"demon" or "pattern-triggered interrupt" by allowing /:TASK and /:SUBTASK 
formulas to be deduced. For example, a BLOCKS-world system may for a time 
have a policy to the effect that a certain block B#72 i 9 to have a clear top. 
This gets translated into the principle, 
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IVX (ON ?X B#72) 

d GT (/: TASK ?T <> 


U 0 (REMOVE ?X B#72)) <>))] 


eff P rt 7 \ * 0n L Bff72 ' Th,S wi 1 ' create 3 task to take it off. A model 

effect of this task is the erasure of (ON B#74 B#72) and with it the task' 

ini s contradicts common sense, since once the interpreter starts to work on 
something ,ts success should not erase it. There may even be serious errors 

r«!i ? a ? T 3n erasure - 9ince the erased task may not have been 
completed yet. In any case, the user may want to ask questions about tasks, 
uithout worry mg about which ones erased themselves. 

.. . is c,ear that this problem has to do with the treatment of time. An 
ctivty can become a task for one reason, but stay a task for another. This 
is handled by the use of the modal operator S, defined as follows: IS ’ I fact I ] 
chn"L t r *°^ e T true '" The inclusion of the given implication 

th i d » b6 K S 3T {/:TASK ?T -••>))]. Exactly the same fact will end up in 
t e data base, but the supporting data dependency will be different. (It is a 
bit wishful to call this a "modal operator" instead of a "patch." If the 
modal machinery were better developed, it could be supported by axioms like 

CT ?R ((S ’?P) a ((TIME) - ?t)) 

3 Gi (VQ (T ?Q (?t < (TIME) < ?t+?i) 

3 ?P)))]. 


but it isn’t.) 

To represent these nuances, the structure of data-dependencies must be 

made more flexible. Before, the supporters list of a dependency was just a 

list of data; now we make it a "labeled tree" of tuples of data. Each label 

explains the role the supporters play in the dependency. For example, a 

BLOCKS-wor I d program might execute the task 

1/:TASK (FIND-OUMP) <> 

(A O (:FIND (X (X) (IS PLACE ?X) )) ) 

<’(DUMP)>] 

in order to find a place to get rid of a nuisance block. If it chooses X - 
TABLE because of a choice principle C, the result 

(-/> ’(DUMP) TABLE) 

wil.l be supported with the two labeled dependencies: 

(DD-CHOICE (IIS PLACE TABLE)) (DD-CPRIN (C))) and 
(DO-INFERER ([FIND-DUMP])) 

where DD-CHOICE, DD-CPRIN, and DD-INFERER label the roles of the formulas they 
dominate in their trees. (I am being a little casual about the format of 


II 
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these structures? when they are attached to the data, pointers to the 
supporting data themselves appear in place of their formulas.) 

Here are some of the implemented labels: 

(DO-ACT-RESULT (|task datum|) 

(DD-APRIN -action principles-) 

(D0-ATR1GGER -action triggers-)) 

relates a task to its results. The action principles are general 
formulas (found in the main data pool GENERAL-DP*); the action triggers are • 
formulas that were true (perhaps transiently) when the action occurred. 

Erasing the latter will not disturb the supportee of the data dependency. 

(DD-CHOICE (-inferential supporters-) 

(DD-CPRIN -choice principles-) 

(DO-CTRIGGER -choi ce triggers-)) 

records an inference for which an answer had to be chosen. The rules 
which contributed to this selection are sorted into triggers and principles 
just the way they are for actions, but, for choices, the supportee is immune 
from disturbances to either of the kinds of choice formula. 

(DD-S (-triggers-)) 

labels supporters whose erasure does not affect the supportee. 

Deducing (S |f|] will record (|f|J with the supporters insulated by a OD-S 
IabeI. 

(DD-INFERER (|task datum|)) 

is attached to formulas deduced or inferred by inferential tasks. This 
is used by other inferential tasks to refer to those formulas. 

(DO-ISTATE (-data-)) 

is used to label formulas, like /:TASK formulas and pvar value 
assertions, which define the state of the interpreter. These formulas are 
"incorrigible," and are never erased. 

(OD-EXEC (|task datum|) (-other data-)) 

records other miscellaneous relations betueen a task and a formula 

(DD-T |data pool| (-data-)) 

links data across reference points. The intent is to record that the 
presence of the data in the foreign data pool are responsible for the presence 
of the supportee (which may be a DD-T itself). 

This information can be dumped out in a revealing form, as described in 


Chapter V. 
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II.E Handling Mistakes 

Consider situations like the following: 

You are dialing a telephone number. Halfway through, you feel your hand 
slip and you know you have misdialed. 

There is a power failure. You wonder if the refrigerator will be damaged. 
You flick the kitchen light switch on to have a closer look. Nothing happens. 

Someone asks you to design an amplifier with a certain high gain-bandwidth 
product. You confidently pick a familiar circuit topology and begin to 
compute the required component values. You discover there are no component 
values that will do the trick. 

All of these are examples of "mistakes." (A finer classification is possible. 
Cf. (Nil sson, 1973).) They all have in common, in the terms I have been 
developing, that the plan for accomplishing a certain task has been shown not 
to work. In each case, it is wholly or partly useless to continue on the 
plotted course. 

Not enough work has been done in AI on correcting such mistakes. (But see 
Nilsson, 1973, Philip Hayes, 1975, Sacerdoti, 1975.) Instead, we have spent a 
lot of effort on seemingly similar search problems in which "blind alleys" are 
searched, and real mistakes never occur. I discussed this briefly at the 
beginning of this chapter. The problem with even the most sophisticated of 
mechanisms for searching through blind alleys (Stallman and Sussman, 197G) is 
that they rely on the ability to restore previous choice points. Previous 
discussion of the problems associated with this (e.g., McDermott and Sussman, 
1972) has focused on the difficulty in choosing a choice point to restore: 
here I wish to call attention to the impossibility of restoring most choice 
points in any useful way. The problem is that the range of choices previously 
available may be obsolete. Sometimes this is because some of the choices have 
been ruled out by other processes. This i3 handled nicely by Stallman and 
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Sussman’s EL (197G). A worse problem is that non-monotonic inferences made at 
the time of the old choice may have been rendered incorrect by further 
discoveries or changes since the old choice. (McDermott, 1974a) For example, 
the range of choices available for instantiating an amplifier can change 
dramatically after adjacent stages are instantiated. There is no way to 
return to one choice point without considering all the choices and actions in 
between. 

The alternative scheme I am about to outline has not been implemented, 
although many of the pieces are in place. 

The idea is to treat correcting a mistake as a task like any other. The 
mistake is given a description by the primitive that failed. (For example, if 
a constraint cannot be satisfied, the mistake is described as (CONSTRAINT- 
COLLAPSE | losing constraint!].) The system sets itself the task 

[/:GET-RID-0F |mi3take description!]. 

Often it will be necessary to re-describe the situation; this is a job for the 
rephrasing protocol. A typical electronic3-domain redescription might be 

(IMPROVE ’(GAIN (STAGE089))]. 

Plans are retrieved to carry this out. (Cf. Chapter I.) 

The difference between this and and a routine situation is that the task 
network must be corrected in some way* Some of the tasks that existed before 
the mistake are still "healthy," else there would be no reason to go on 
living, but some of the subtasks are now "rotten," and may be replaced. A 
subtask of a /;GET-RID-0F task is allowed to alter certain parts of the task 
network. 

Making the network-editing machinery work is the hardest part of 
implementing this scheme. The kinds of edits that must be allowed include 

> Adding new subtasks to correct the problem.. The commonest reaction to 
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an accidental "protection violation" (Sussman, 1975) is to re-establish the 
protected fact without further fuss. 

> Restarting old subtasks. For example, the string of tasks involved in 
dialing the first digits of a misdialed telephone number must be resurrected. 

> Detaching and redescribing old subtasks. For example, introducing too 
much feedback can cause oscillation; its old description (that it did 
something useful) must be discarded, and it must be seen as part of the 
problem instead of part of the solution. Its old supertask must be marked un- 
/sREDUCED again, and a new way must be found to solve it. 

> Terminating active subtasks, especially policies, of a rotten task. In 
electronics, constraints derived from circuit diagrams must be removed when an 
IMPROVE task is executed and changes the topology of the circuit diagram. 

The information about what edits are legal must be part of the mistake 
handler. For example, the plans regarding constraint collapse (see Chapter 
III) must specify that the highest task that is the scope of some of the 
collapsed constraints is still healthy; some lower-level task (probably 
associated with a particular canned circuit diagram) must be declared rotten 
and its policies abandoned. 

The reason why this scheme has not been implemented is that it depends on 
the data-dependency machinery I described, which is still relatively untested 
itsejf. Undoubtedly both of these systems will grow together. 


11 - F Programmer’s Guide 

As I said, NASL '13 not exactly a programming language, but it’s not a 
natural language either, so it is probably best for the programmer to approach 
it first as the kind of formal language he understands best. To help with 
this, I include "programmer’s manuals" in each of these three tough chapters. 

NASL has two interpreters— the theorem prover (STP) through which all 
NASL formulas must pass, and the plan interpreter (NASL proper) which takes 
some conclusions to be instructions to act. The first design decision in 
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expressing a new set of facts in NASL is whether to rely entirely on STP or to 
cast them as rules which create and manipulate tasks. 

In principle, everything could be handled by the theorem prover. For 
example, axioms could be introduced defining a space of electronic circuits, 
and constructively proving 

[EXISTS (X) (AND (ELECTRONIC-CIRCUIT ?X) 

(|P| ?X))] 

could replace the action (DESIGN |P|], 

As we all know, however, all theorem provers of STP's class rely heavily 
os? the generate-and-test problem-solving method. Generating all circuits is 
obviously ridiculous. 

Here are some more general criteria for deciding whether to represent a 
body of facts as axioms or plans: 

(1) As R. Moore (1975) has pointed out, it is a strong clue that a theorem 
prover is out of place when side effects enter naturally into the statement of 
a body of knowledge; this is certainly true for design. Any irreversible 
action, such as asking a question or wiring a circuit, rules out the use of a 
raw theorem prover. 

(2) If you wish to take advantage of information relevant to a choice 
point, the choice must come up as the choice of a uay to do a task or of the 
answer to a /:FIND. (You should verify that the information is worth the 
trouble.) 

; ^3) If subgoals arise which must interact, you mu 3 t put the goals in the 
data pool, i.e., make them tasks. Similarly, if you wish to manipulate goals 
as data structures, you must add rephrasing knowledge for tasks of that type. 

Only if it appears that only brute-force deduction is necessary or 
feasible should you cast the knowledge as pure axioms. An example is the 
theory of frequency-picture manipulations developed in Chapter IV. Commonly a 
class of tasks will be associated with a "mini-theory" of some characteristic 
criterion for choosing between them; this little theory is expressed in terms 
of pure axioms. For example, the theory of ordering the selection of 
component values uith respect to other tasks (Chapter III) is a small set of 


n 
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axioms. (The merits of this "clever cogitation directed by brute-force 
retrieval" organization will be discussed in Chapter VI.) 

II.F.l Predicate-Calculus Techniques 

Even after you have decided to represent a body of knowledge as a set of 
facts about tasks, these facts must be expressed as predicate-calculus 
implications. The approach to this that I have found useful is to think of 
them independently of their use first, concentrating on what they are to mean. 
Once this is done, the pragmatic content can be added. This approach forces 
you to think about what you really mean to express. For example, when you 
write an implication of the form t|P| o C/s TASK ...)], do you really intend 
that this task exist only while P is true? 

There are three pragmatic decisions to make; whether to express 
implication as /sCONSEQ, /sANTEC, or /:GEN; where to use packets; and which 
version », or «/>) of equality to use; 

The first decision is often simple. Systems of predicate-calculus rules 
develop in such a way that one layer of rules "feeds" the next during forward 
and backward deduction. The rules usually work together to record in a 
forward fashion up to a point; then backward (consequent) rules work their way 
from deductive goals to the formulas recorded by forward rules. Generative 
("-/> G") rules are useful in mixing these processes up. So, for instance, it 
is no use having an antecedent rule if no one records an expression matching 
its left-hand side. R. Iloore (1975) has given some useful hints in deciding 
which way implications can be used. 

/:PKT should be used instead of AND on the right-hand side of an /:ANTEC 
when much of the contents of the conjunction are not looked at for most 
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instantiations, or if it is not necessary that they trigger further /rANTECs 
immediately. This is true, for example, of circuit diagrams, where 
information about the purposes of components is not always accessed: but not 
true of plan schemata, where all the tasks and subtask relations are going to 
be recorded anyway (and the interpreter must notice every task). 

It is usually clear which version of equality to use. Goals are usually 
phrase in terms of but if you know there is only one simple answer, use 

/:**," which merely matches the two sides against each other. Simple "«*" Mill 
work harder in the case where they don’t match. Often does not have to 

mentioned in the rules where it it is used; if rules like [«/> ’ (F A) B) are 
around, they will be applied when the right-hand sides of implications like 

[-/> A (P ?X) (Q (F ?X))J 

are detached with the variables bound. That is, recording (P A] will cause IQ 
BJ to be recorded. 

Finally, remember that it is not always enough to supply axioms about 

proving propositions with a certain predicate; if you ever wish to disprove 

such propositions, you must supply appropriate axioms. Often disproof 

information can be summarized uith a single PRESUMABLY statement. For 

example, in the world of blocks, we might have 

[-/> C (AND (ON ?X ?Y) (ABOVE ?Y ?Z)) (ABOVE ?X ?Z)) 

[-/> C (ON ?X ?Y) (ABOVE ?X ?Y)] 
tPRESUMABLY ’ (NOT (ABOVE ?X ?Y)) CJ 

The effort to prove tNOT (ABOVE A B)I will cause (vfa /sCONSISTENTLY) an 
effort to prove A Is above B; if it fails, the conclusion is taken as true. 
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II.F.2 NASL Programming Techniques 


In applying NASL to a new problem domain, one must supply mode I- 
manipulation statements to actually get things done, and indexed plan schemata 
to orchestrate them. 

Tasks may be reduced in a forward or backward way. In the former, the 
presence of a task can trigger deductions of subtasks. For example, in the 
world of blocks, one could specify a plan to the clear the top of a block 
thus: 

[-/> A (/: TASK ?N <> (X 0 (CLEAR ?X)) <>) 

(-/> A (-/> ’(/:TASK-STATUS ?N) ACTIVE)) 

(FORALL (Y) 

(-/> A (ON ?Y ?X) 

(S ’(EXISTS (T) 

(/:TASK ?T <> 

(X 0 (PUTON ?Y TABLE) ) 

<>) ))) ))] 

(Notice the use of "S" to indicate that these tasks are being triggered, not 

supported, by the statement (-/> ’(/: TASK-STATUS | task |) ACTIVE).) 

In backward reduction, plan schemata are instantiated via /:DO-SUBNET 

calls. This requires a couple of formulas. In the same blocks world, we 

might have the formulas 

[/: TO-DO ?TSK (ACHIEVE ’(ON ?X ?Y)) <> 

(/:DO-SUBNET (ACH-ON ?X ?Y) <>)) 

(-/> A (/:PLAN-INSTANCE ?PI (ACH-ON ?X ?Y) 7SUPER-TASK) 

(AND (/:TASK (CLEARER-1 ?PI) <> (X 0 (CLEAR ?X) ) <>) 

(/:TASK (CLEARER-2 ?PI) <> (X 0 (CLEAR ?Y) ) <>) 

(/:TASK (PUTTER ?PI) <> (X 0 (PUTON ?X ?Y) ) <>) 

(/:SUCCESSOR (CLEARER-1 ?PI) (PUTTER ?PD) 

(/:SUCCESSOR (CLEARER-2 ?PI) (PUTTER ?PI)))1 

The interpreter, when it has decided to reduce (ACHIEVE ’(ON ...)) using the 

first rule, will create an instance of the schema [ACH-ON ...); the second 

rule will then trigger the creation of several subtasks. 
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A corpus of NASL rules is often written as an incomplete set of plans and 
axioms, which is then debugged by adding "interaction terms," i.e., knowledge 
which influences the application of the first-order rules. This occurs 
through the medium of these kinds of rules: 

> Rephrasing rules which redescribe actions, usually by breaking them into 
pieces and putting them back together. 

> Choice rules which influence the way in which tasks are reduced. 

> Rules specifying /:SUCCESSOR relations. 

> Policies to watch for interactions between tasks or to influence 
choices. 

Ue will see plenty of examples of NASL plans and rules in the following 


chapters. 
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III Design of Hierarchical Systems 

Design is the production of an object to satisfy certain requirements. 

The requirements may describe the desired object closely ("A stick 18 inches 
long"), or they may be very remote from what is finally produced ('Something 
to make this room look more friendly.") 

Of course, designing does not mean actually manufacturing an object; what 
is actually produced is a detailed description of one. In fact, design might 
be described as the process of adding detail to a description until ful I 
detail" is reached relative to some basis. 

In what foilous, I will elaborate this theory, and then explain hou it is 
implemented as a set of NASL rules. (A close relative of this theory was 

outlined by Freeman and Newell (1971) in a paper called A Model for 
Functional Reasoning in Oesign.”) 

The best uay to explain it is to start at the bottom, near the basis. 

The basis for a design domain is a set of primitive artifacts. For example, 
if sticks are primitive, designing a stick 10 inches long is merely a matter 
of "instantiating the stick primitive." "Instantiation" means creating a 
symbol, such as X043, and recording that it denotes a stick. That is not all, 
however. Associated with the primitive "stick" are attributes such as its 
length, width, material, color, etc., which must be fixed for a concrete 
instance of it. Because it is a primitive, we may assume that fixing a 
stick’s qualities is merely a matter of choosing them. (Uooden sticks are 
cheaper than platinum, but I will not consider cost explicitly in this paper. 

I emphasize finding any solution to a design problem, not finding the best 
solution.) 

So designing a stick is just a matter of picking a name, a uidth, and a 
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length. (Assuming broun wooden sticks from now on.) If the length is 
constrained to be 10 inches, that is clearly the length to pick. The width, 
if unconstrained, may be picked arbitrarily, subject to the reasonable 
constraint on all sticks that their width be no more than 10% of their length. 

For a primitive artifact, then, "adding detail" is just selecting values 
for its "control attributes," such as length and width. 

This theory of design will not account for the design of "something to 
make a room more friendly," mainly because "object that makes a room look 
friendly" is not a primitive artifact with a fixed set of attributes. In 
general, a requirement may be arbitrarily remote in structure from the kind of 
object that satisfies it. 

So it is necesary to provide for for the Indexing of partial solutions by 
their important features. That is, the theory must just provide for 
statements I ike, 

"Funny posters make a room more friendly." 

"Plants make a room more friendly." 

"If x makes a room more friendly, and y (distinct from x) 

makes a room more friendly, usually the combination of x and 
y makes a room more friendly." 
etc. 

A partial solution of this kind may be a primitive artifact, in which case 
the problem has been solved, but more generally it consists of a structure of 
design subproblems. These subproblems must be solved in much the same way as 
the original problem, and the solutions must be connected up. Eventually the 
original problem will have been completely reduced to primitives. (Fig. 

111 . 1 ) 
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Figure III.l Function-Structure Graph 
These primitives will be connected and constrained. Some of these 
constraints come from the problem (e.g., "Amplifier with gain - 10"), some 
from the partial solution ("A common-emitter’s gain is beta X R|_/Rg"), some 
from connections ("The current from R^ is the current into the collector"), 
and some from descriptions of primitives ("The resistance must be positive"). 
As with the simple stick problem, the control attributes of the primitives 
must all be selected subject to the constraints. 

The design process suggested by Fig. III.l neglects several complications 
having to do with pragmatic knowledge of partial solutions. Some of these 
will be easier to talk about after I introduce the NASL implementation of this 
design theory. Before I do that, I should say more about the "indexing" of 
partial solutions. 
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If a design requirement is very simple, it is is plausible to imagine it 
as calling to mind a partial solution tagged with "specs" which match the 
requirement. For example, the design problem "flake a common-emitter 
amplifier" could plausibly match the specs on the common-emitter circuit 
exactly. 

For more complicated problems, this will not work. The description might 
contain conjunctions, disjunctions, or quantifiers. It might consist of 
simple pieces whose solutions can be composed. It may be cluttered with 
numbers which have to be described more suggestively, as in the example of 
Chapter I, in which "gain ■ 10" uas replaced by "moderate gain." Finally, the 
description might just be in the wrong terms; a common example in electronics 
is the translation between time-domain and frequency-domain descriptions of 
signals. 

So the theory must provide for manipulation of problem descriptions, 
before the first partial solution can be proposed. This manipulation is aimed 
at transforming a description into a form suitable for retrieving stored 
partial solutions. 

A version of this theory has been encoded in NASL. As coded, it is 
independent of electronics, although enough restrictions have been placed on 
it to keep me from claiming it is a complete general design theory. It is 
meant to be a theory of engineering design, for which, to first order, all 
effects can be thought of as local interactions among connected modules, each 
of which is designed to accomplish some part of an overall objective. It is 

biased toward systems whose interactions can be described numerically. I will 
call this domain "design of hierarchical systems." 

It is straightforward to express in NASL most of the concepts I have 
outlined. The first step is to implement the notions of "requirement" and 
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"structure fulfilling it" as tasks and subtask3. That is, a design problem is 
expressed as a task, and the terminal nodes of the function-structure graph 
are to be identified uith primitive tasks of the form "grab a (primitive) 
component." For example, a first-pass analysis of an electronics problem may 
generate this structure: 


Acquire 
Stage 1 


q Make a cascade 



O 


O Couple 


O 


Acquire Stage 2 


Figure 111.2 A Two-Stage Cascade 
Later elaboration will instantiate the coupling task: 
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Figure II1.3 An LC-coupled Amplifier 
"Partial solutions" are implemented as a kind of plan schema. A 
particularly important kind of partial solution is a device type, a packet of 
facts clustered around a concept like "amplifier," or "operational amplifier," 
or "resistor." Some of these facts describe the structure of the devices of 
the given type, but many of them are concerned with how such devices are used 
in solving larger design problems. Thi3 last 3et of facts defines a set of 
tasks for elaborating a device and connecting it to its peers. 

Primitive devices are those with no internal structure, whose elaboration 
consists mainly of selecting values for their control attributes. The system 
represents these obligations as a set of "SELECT-VALUE" tasks. The 
constraints that accumulate during a design are implemented as policies which 
influence the execution of SELECT-VALUE tasks. 
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Because we are using the NASL interpreter, all design subproblems are 
represented explicitly in the data base as tasks. Partial solution plans are 
recovered, as for all tasks, by using STP to retrieve them. Choice rules are 
used to choose among or compose sets of partial solutions. Simultaneous 
subproblems are represented by simultaneously active tasks. There are 
frequent cases where it is important to start on one problem before another, 
because the solution to the first will influence the choice of approach to the 
other. This can be arranged by writing rules to cause the deduction of 
/sSUCCESSOR formulas. 

The manipulation of requirement descriptions when routine indexing fails 
to retrieve a partial solution is handled by a special design rephrasing plan. 
It says to turn a recalcitrant design task into a task network of the 
following kind (cf. Fig. 111.8): make a device of a known type, and constrain 

it. The plan is to do this by tearing the given problem into piece9 called 

shards (usually conjuncts from the design requirement), each of which is 
classified as specifying either the device type or a constraint. The plan 
succeeds only if every shard is accounted for in one of these ways. It is 
generally the responsibility of rules from domain-dependent plans to make sure 
this is true. In the electronics domain, as we shall see, there are many 
rules for manipulating shards, ranging from those which convert shards 
regarding gain into control-quantity constraints, to those which change 
signal-conversion shards from the time domain to the frequency domain. 

This is a broad outline of the design theory encoded in the formal theory 
of OESI. (Appendix 2) A point to notice in its exposition is that I appealed 
to innate control concepts to explain notions of structure, purpose, and 
constraint. It will be seen that appeals like thi3, appropriately formalized, 
are the only kinds of knowledge of these concepts that DESI has. In a 
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primitive way, the program exhibits "machinomorphi sm," the inclination to 
understand other systems in terms of its own kinds of motives. This allows a 
certain computational economy, and makes assimilation of new information more 
reliable by enforcing a small vocabulary. A complicated and delicate (or 
electronics-dependent) theory of purpose and commitment does not have to be 
added by the user. 

Before turning to a detailed exposition of the DESI implementation, I 
should mention three issues I will have little to say about: learning, search, 
and creativity. The last of these may seem the most important. Many people 
would probably be skeptical about the ability of a machine to do design, 
because creativity seems to be absent from machines and vital to design. 
Indeed, "design" and "creativity" seem almost to be defined in terms of each 
other. If this issue bothers you, let me call your attention to the 
distinction between "routine" and "imaginative" design. Routine design is the 
production of an artifact in a field (such as electronics) such that anyone 
else with an ordinary mastery of the field could have produced the same thing. 
This kind, of design is the only kind I can claim to have a theory of. 

DESI does not learn anything from doing a design. Although at the 
beginning of this chapter I described designing as adding more detail to a 
description, the description at the end of a design is not represented the 
same way as the problem description. The problem description is essentially a 
A-expression, but the final result is a set of statements in the data base 
about "X043," or whatever symbol was chosen to represent the target device. 

To learn, DESI would have to gather these statements together into a new plan, 
and index it under a useful generalization of the problem. Doing this is 
difficult. (Cf. Sussman, 1975) 

Other kinds of learning are also possible. One can imagine a program 


M 
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learning how to order certain kinds of subproblems, or how to choose and 
compose partial solution. These are examples of "trial and error" learning; 
to attack them requires a theory of search. 

□ESI, like all NASL systems, tries, never to make a choice at random, and 
never backs up to undo a choice. (See the discussions in Chapter II.) Thus, 
it can be said not to search at all. This is the right organization, but it 
needs to be combined with a learning system that proposes new choice 
principles by watching what happens after it does make an arbitrary choice. 

For example, if one amplifier circuit is chosen from several that satisfy the 
knoun choice principles, and later its impedance is discovered to be too high, 
the system should not back up, but should make up a new choice principle to 
rule that circuit out in case high impedance is required. 

The system currently does none of these things. If its rules get it into 
trouble, it will look for a correction plan that fits the situation, but will 
do the same thing all over again if the next problem is similar. This is a 
serious, but (I hope) temporaray, defect in the theory, since it seems clear 
that people learn something new in the course of all but the most routine 
design tasks. 

As I describe in detail DESI's design theory, I will point to the more 
formal exposition of Appendix 2. By looking there, you will be able to judge 
the power of the NASL control language. It will be seen exactly how often it 
is directed and flexible, and hou often clumsy, arbitrary, or inextensible. 
The important point at issue during this otherwise tedious exercise is one’s 
ability to represent various specialized control and debugging strategies 
using the framework of tasks, data-dependencies, and conflicts described in 
Chapter II. In what follows, references to the formulas of Appendix 2 are 
indicated thus; <*formo7a-name>. 
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111. A The Representation of Knowledge about Devices 

Much of design is the manipulation of devices. A device is any 
man i pul able, "physical'' object in a design domain. (Thus, signals will not be 
devices, but nodes will be.) Familiar classes of devices that are useful are 
called device-types. These classes may be formed in several ways. (Sect. 
III.A.l) Each device in a class is described by a set of formulas arranged in 
certain standard ways. (Sect III.A.2) A set of formulas describing a device 
type is instantiated to form a particular device’s description. Knowledge 
about a device type is therefore conveniently represented as a ” packet" 
(McDermott, 1975) of facts which is instantiated when a particular example is 
considered. This packet is called a device schema. (Unfortunately, Brown and 
Sussman (1974, A. Brown, 1975) have used the term "plan" for this purpose. 

This conflicts with the usual range of meanings of this term in AI. I have 

used this term in the more traditional meaning already in discussing the 
interpreter.) 

III.A.l Hierarchies of Device Types 

Device types which have a recognizable function and circuit diagram (or 
8ymbo,) are called basic. Basic device types may be lumped into loose classes 
called superordinate device types. <*DEVICE-CLASSES> (This terminology is 
borrowed from (Bobrow and Uinograd, 197S), but I am not sure I mean the same 
thing by it that they do.) Sometimes such a higher class exists just because 
people have a name for it and use it to specify problems. An example is 
"amplifier." Sometimes there is some class of facts it is convenient to store 


together, as for "2-terminals. 


(See Chapter IV.) 
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Kinds of Device Type 
Basic 


Primitive 

(e.g., 

resistor) 

Composite 

(e.g., 

common-emitter amplifier) 

General 



Specia 1ized 



Ideal 

(e.g., 

current source) 


Superordinate (e.g., amplifier, 2-terminal) 

Figure 111.4 A Hierarchy of Types of Device Types 

Basic device types may be further classified <*BASIC-DEVICE-CLASSES> as 
primitive, composite, and ideal. Primitive devices are the terminals of a, 
complete function-structure graph. (See belou.) Ideal devices such as current 
and voltage sources behave as primitive devices, but must be "implemented." 

Canned devices that are made up of simpler components are called composite 
device types. Textbook diagrams of things like Hartley oscillators and 
common-emitter amplifiers may be taken as standard examples of composite 
device types. Often these textbook diagrams leave implicit uhat I take as an 
important feature, that they exist in general and specialized versions. (Fig. 
II1.4) <*GENERAL-DEFN> The general common-emitter amplifier, for instance, is 
just a transconductance treated in a certain way, whereas the "typical common- 
emitter" has biasing resistors hung all over it. (Cf. Uatson, 1970) This is 
expressed as 

[DERIVED TYPICAL-CE GENERAL-CEI. 

The importance of thi3 relation will be brought out shortly. 

Thus a particular device will be at the bottom of a hierarchy of general 
and superordinate devices. (Fig. 111.5) 
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I-► 

= SUB-DEV-TYPE 


= DERIVED 


= SPEC-DEV-TYPE 



Sig-Transer 


Amplifier 



SUPERORDINATE 


BASIC 


SPECIALIZED 


Figure III.5 Devices in The Type Hierarchy 
The relation between the devices above the BASIC level in Fig. 111.5 is [SUB- 
DEV-TYPE |dev type| |superordinate dev type|l. Belou that level, the relation 
is tSPEC-DEV-TYPE | specialized dev type | |dev type |}. Thus we would write 
[SUB-DEV-TYPE COMMON-EMITTER AMPLIFIER] and tSPEC-DEV-TYPE TYPICAL-CE COMMON- 
EMITTER]. (The DERIVED relation will be explained below. Sect. III.A.2.) 

A device will be of several device types, written [DEV-TYPE |dev| | type 13. 
There is usually one, its MAIN-DEV-TYPE, which is the most specific category 
It is known to fall in. 


111.A.2 The Representation of Device Diagrams 

A device is either primitive or composite, depending on its main device 
type. A device is specified with several kinds of information (most of them 
are not necessary for primitive and ideal devices): 
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(1) The components of devices of that type. This is kept in formulas of 
the form 


CCOHPONENTS |dev ice| < -component names- >1 

Each component is itself a device, whose main device type is expressed by a 
separate formula. For example, for a voltage divider VD#21 we might have 

[COMPONENTS VD#21 <(R1 VD#21) (R2 VD#21)>] 

[MAIN-DEV-TYPE (R1 VD021) RESISTOR] 

[MAIN-DEV-TYPE (R2 VQ#21) RESISTOR] 


(2) Connections and constraints between components. There can be no 
domain-independent notion of connection between physical objects, since any 
physical medium can be exploited. The only completely general thing that can 
be said is that connecting devices "constrains" them in some uay. 

(Otherwise, there would be no point in connecting them. Cf. "C0NSTRAINT2" in 
Fig. III.l.) As we shall see below, there is a rich theory of constraints 
built into DESI. 


(3) Control quantities. These are numerical-valued attributes of the 
device that the designer has complete or partial control over. They are 
represented by formulas like 

[CONTROL |attribute| |device| |range| |degree of control|J. 

This declares attribute to be a control attribute; it means that the quantity 
[|attribute| |device|] may be assigned any value from the set of numbers 
range. Since real components often vary from their nominal values, the 
formula specifies the degree of control of the attribute, which is the 
quotient of the highest and lowest possible true values compatible with the 
selected value that appears in the data base. This value is actually the 
(geometric) mean of highest and lowest values. These uncertainties will be 
taken into account in reconciling constraints. As an example, in electronics 
for a transistor Q#173 we might have 

[CONTROL BETA Q0173 (INTERVAL 10 500) 10], 

since the beta of a transistor is controllable only to within an order of 
magnitude; while 

[CONTROL POLARITY Q#173 <+l -1> 1], 

since every transistor is unambiguously PNP or NPN. 

A distinction must be made between Immediate control quantities and 
derived control quantities, corresponding roughly to attributes of primitive 
and composite devices. There are several relevant formula types for 
expressing information about these matters: 


(a) [IMMEDIATE-CQ ’|control quantity|] 

Example: [IMMEDIATE-CQ ’(RESISTANCE R#21)] 
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(b) IDERIVED-CQ ’|control quantity|I 

Example: IDERIVED-CQ ’ (V-GAIN AMP#34)] The actual function 
relating the V-GAIN of the amplifier to the values of its components' 
control quantities can be derived from constraints found in the 
description of AMP#34. Often these uill be found in the device schema of 
which AMP#34 is an instance. 

(c) [GENERIC-CA |attribute|] 

Example: [GENERIC-CA THEV-R] It would be tedious and wasteful to 
derive a formula for each device or device schema relating its Thevenin 
resistance to its components' values. (A change of topology, for 
instance, would force a recomputation.) Instead, some control attributes 
can be declared generic, meaning the system knows how to compute them and 
will when they are needed. (The current system can handle this to the 
point of enqueueing a CALCULATE task, but the computational techniques 
required have not been implemented.) 


(4) Task Information. Every device has a cloud of tasks floating around 
it. These will be of various sorts: 

> The purposes of a device and its components are represented by a set 
of finished tasks associated with acquiring them. 

> Many devices will not function as they are supposed to without further 
work ("subrequirements" in Fig. III.l); these active tasks are called 
expansion obligations. These ride along on most composite devices and even 
some primitive ones; a transistor, for example, must be biased into its 
intended mode. 

> A device carries along monitors on the topology of the connections 
inside it and from it to other devices; some of these monitors are for 
protection of important relationships, and some just to notice when something 
must be recomputed. 


These are characteristics of devices. A device schema is merely a canned 
set of such formulas with a free variable to be bound to a particular device 
when it is made. Device schemata are used to represent device types. They 
are usually implemented as "packets." (McDermott, 1975) For example, the 
packet for "voltage divider" will include the formula 
[COMPONENTS ?##VD <(R1 ?##VD) (R2 ?##VD)>I 
from which the formula given above for VD#21 will be derived. The prefix 
"?##" specifies that ?##VD is a variable loosely bound to an "abstract voltage 
divider." The formula says, "the typical VD ?X has components [R1 ?X] and [R2 
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?X1.") 

The tasks that uill be liberated when a device schema is instantiated are 
called frozen tasks, and the liberation process is called "thawing." Frozen 
tasks may be thought of as mummified remnants of actions that were 
(conceptually) executed when the device schema was first put together. 

(Device schemata are to be thought of as the result of previous designing 
activity followed by summarizing what was learned, but this is just to help 
your imagination; such a learning scheme doesn’t exist yet.) One thing that 
must be left around in a schema is a record of why the various components were 
acquired and connected as they are now found; in other words, the purposes of 
the components. (If for no other reason, these are necessary in case they 
have to be undone during mistake correction.) 

The simplest way to accomplish thi9 is to keep the tasks that were known 
at the end of the (imagined) design episode in a frozen state. Some of these 
will have been FINISHED; for example, the tasks that acquired the components 
are there just to record why they were acquired. Others are still active. 

For example, there will be ACTIVE constraints and protected model 
manipul ations. 

By way of illustration, a voltage divider may be first thought of as a way 
of setting a bias voltage in a particular amplifier design problem. A voltage 
divider found in a schema must be associated with a policy of keeping that 
bias voltage set. 

An advantage of the frozen policy solution compared to a more specialized 
implementation of purpose comments is that one mechanism is used to handle 
local cooperation and conflict of tasks as well as interactions of new actions 
with old purposes. This is an example of the "machinomorphi sm" I mentioned at 
the beginning of this chapter. 
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Specialized device types are arranged in a hierarchy according to the 
DERIVED relation. This is a more complex relation than SUB-DEV-TYPE and SPEC- 
DEV-TYPE (cf. Fig. 111.5), which are used mainly to cause properties of higher 
types to be inherited by lower. <*SUB-DEV-TYPE-1, SPEC-DEV-TYPE-1> Dost of 
the properties of a general circuit, such as its topology and components, ar.e 
not to be inherited by its specializations. Houever, there is an important 
class of properties which must be accessible from the specialization: the 
frozen tasks of its more general counterpart. The relation between a general 
circuit and its specialization is precisely that the expansion obligations of 
the gerieral circuit are fulfilled by the structure of the specialization. 

To represent this relation, we need some more equipment. Every device 
thawed from a schema ha3 a "deep freeze" of frozen tasks, which are collected 
for convenience as the subtasks of an abstract task called the [DEEP-FREEZE 
|device|I. If dev-type 1 is derived from dev-type 2, then a device of type 1 
will have a "SOUL" which is a device of type 2. <*S0UL-0N-ICE> The important 
relation between them is that every subtask of the soul’s deep-freeze is to be 
a subtask of the original device's deep-freeze. This inheritance i 3 done via 
/iCONSEQ deduction, since it is not important to see every frozen task during 
normal operation; most of them will have been reduced anyway. They are mainly 
valuable in explaining the purposes of components. 

For many examples of device schemata, see Appendix 3. 
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III.B Design Actions and Plans 


I can go no further in talking about devices without talking about design 
actions. This is because devices’ purposes are so intimately associated with 
the purposes of their designer, in this case DESI; and DESI’s purposes are 
expressed as tasks. 

Design actions fall naturally into these classes (see Fig. III.6): 

(1) "Design something with property p": Starting with no structure or hint 
of it, one is to produce such a thing. 

(2) "Hake an x": Here x is a device type, an example of uhich is to be 
created. This kind of action breaks down into subtypes, depending on what 
kind of device type x is. Making a basic type tends to be a matter of 
choosing which version along the specialization scale to use, then plugging in 
its frozen tasks. Making a superordinate type requires more involved and 
careful choice, since the sub-types to choose from usually have incompatible 
properties. 

(3) "Constrain something": Things that can be constrained are not devices, 
but quantities. There are two classes: physical quantities such as voltages 
and currents; and the control quantities, such as resistances and power gains, 
that I described above. 

(4) "Change a device": Given a structure, it can be altered in various 
ways. These actions include fixing a physical quantity, biasing a circuit, 
adding feedback to improve stability, and coupling two stages. The actions 
are defined by plan schemata that often come in specialization hierarchies 
like those of devices. A major subdivision of these are actions which involve 
changing the previously reigning plan network as well, for example, altering a 
control quantity which is already fixed by constraints. 

This list is derived by common sense, and from perusal of 100 Ideas for 
Design (Electronic Design, 19G4), among other works. (Senturia and Wedlock, 
1975 ) 
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Design Actions 

1 DESIGN 

2 MAKE 

superordinate 
primitive 
ideal 
general 
specialized 

3 Constrain 

CONSTRAIN 

SELECT-VALUE 

4 Change 

FIX quantity 
BIAS 
COUPLE 
Patch 

IMPROVE gain, input-Z, selectivity,... 

Figure III.G Design Action Taxonomy 

The design problems which appear in books such as these include 

"Design a power amplifier..." (Type 2) 

"Increase the current..." (Type 4) 

"Isolate two connected devices" (Type 4) 

"Make the quiescent output voltage 40V" (Type 3) 

"Design a circuit with a high gain-banduidth product" (Type 1) 

"Avoid loading" (Type 3) 

(There are other kinds of actions, such as "simplify a circuit," which I have 
not counted as among these types. I hope they can be added, but I have no 
plans to do so.) 


III.B.l OESIGN 


There is only one action in this class. 

[DESIGN |prop|] ««> I<|name|>) 

This action usually arises at the top level. Successful execution of such 
an action creates a model of a device that has property prop. In easy cases. 
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Figure 111.7 Design Rephrasing Plan Schema 
This is a plan to manipulate the design problem as an object. 


The plan 


network is set up using a formula <*+DESI-l> uhich extracts the desired 


n 


Ofind d-features 
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predicate as the value of ?+P. In this context, the embedded formulas, 
prefixed with the character are being used essentially as SNOBOL patterns 

(Farber et. a?., 1964) to tear the goal to be rephrased into manageable 
pieces. So ?+P will have value 111prop13 J. (See Appendix 1.) 

Remember that the final aim of a rephrasing task is a revealing reduction 
of its target task. A detailed analysis of the problem may be postponed; the 
important thing in rephrasing '13 to make it "familiar." The goal in the case 
of the design rephrasing plan is to reduce the design problem to the following 
net: 

I side-tasks 

(usually CONSTRAINS) 

Figure 111.8 Rephrased Design 

The strategy of the designer is to "explode" the given predicate into "d- 
8hards," which are conjuncts of the original predicate. Discovering d-shards 
is occasionally straightforward <*D-SHARD>, but usually depends upon formulas 
for the domain involved. (See Chapter IV.) 

The d-shards are valuable only insofar as they lead to one of three 
things: 

(1) A core-device-type the MAKing of which is the simple first step of the 
rephrased design plan (Fig. 111.8); 

(2) Side-tasks, typically to enforce numerical constraints discovered as 
d-shards; 

(3) D-features, qualitative predicates used as policies in making a core¬ 
device-type. 

This fact is expressed as the policy task ACCOUNT-FOR-ALL, which says to 
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make sure that every d-shard Iead9 to one of these three things. In the 
current implementation, it is an error if a miscreant shard is discovered. A 
mdre sophisticated implementation uould know how to try harder and attempt to 
learn from its efforts. 

The only other feature of interest in the general design rephrasing plan 
i3 the step CORE-FINDER, during which NASL must find the core device-type to 
be used. The core device type is often clear from a d-shard of the form ItX 
(|l/|) (DEV-TYPE ?|v| |dev-type|)]J <*C0RE-DT-1>. However, rules from 
particular domains can and do suggest device-types based on more elaborate d- 
shard processing. The interpreter must choose one. It is the responsibility 
of the writer of this knowledge to provide choice rules to get out of thi 9 
situation. However, there is one rule <*C0RE-0T-CH00SE> which is domain- 
independents if one device type is subordinate to another, reject it. (It 
should be suggested later anyway by the policies that grow out of d-features.) 

This rephrasing method may be compared with the proposal of Moore and 
Newell (1974) for the MERLIN program. The idea there was to be able to "view" 
any conceptual structure as another by a process of mapping the pieces of one 
into the pieces of the other. DESI tries to view any design problem as 

making a ..., while noticing hints +++, then doing-this template may be 

seen as a three-slotted structure, such that every piece ("d-shard") of a 
design problem goes into one of these slots. The process is more structured 
than MERLIN; in particular, this kind of rephrasing is not an operation which 
can always be done by def ini t ion; it is capable of failing. The analogy may, 
however, be revealing. (It was suggested by Marvin Minsky.) I suspect that 
many rephrasing problems can be put in this paradigm form, and that the 
rephrasing protocol can be made more specific. However, currently DESI does 
things with rephrasing which cannot be 9een as an instance of this paradigm. 
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(An example is equation solving.) 

III.B.2 flaking Things 

(1) (MAKE | dev ice type11 »«> [<|name|>] 

The intent of this action is to create ("buy") a device of the indicated 
type. If the device type is basic <*MAKE-BASIC-PLAN>, a task net is set up 
with a primitive GRABBA action, uhich Mill just generate a new symbol and make 
its main-dev-type be the basic type. Extra tasks are hung on the network, 
depending on whether the device is primitive <*MAKE-PRIM>, composite <*MAKE- 
C0MP0SITE>, or ideal <*MAKE-IDEAL>. In the case of primitive devices, the 
only commitment enqueued is to select the values of its control quantities. 

In the case of composite devices, the plan subnetwork includes a subtask to 
expand the device at some time in the future. Ideal devices receive a 
commitment to be implemented. (These new tasks are not marked /:MAIN in their 
task networks, so they do not have to be finished before the successors of 
their supertasks are begun; hence, they amount to future commitments.) 

Expansion of a composite circuit means wiring up a circuit diagram for it. 
Usually this just means selecting a specialized device type and declaring the 
circuit to be that type; this is called "specializing" the circuit. 

<*SPECIALIZE-DEFN> The system has a choice of circuit diagrams from the 
specialization hierarchy. If one circuit is DERIVED from another (and hence 
is "specialized"; see Figs. III.4 and III.5), it will do the same task, but 
may depend on more specialized assumptions. It is the user’s job to write 
rules that suggest circuit versions to match requirements, but the system 
knows about two peculiar specializations of a circuit: its "most general" 
specialization and its default specialization. <*MOST-GENERAL-DEFN, DEFAULT- 
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^PEC-DEFN> If either of these is available, it will be suggested. Generally, 
only one specialized device type of some basic type will come up in a given 
context. The user must make sure that good choice rules are available when 
more than one appears. The trade-offs should be clear: a general schema 
involves more work on expansion-obligations, but using a specialized version 
runs the risk of having to correct the circuit topology when some assumption 
proves unjustified. 

If the user s rules do not sufficiently disambiguate, the system uses the 
two rules <*SPEC-DEV-BETTER, TUO-SPEC-DEVS-UORSE-THAN-ONE>. The first 
encourages the use of a more specialized device type if it has been suggested; 
the second overrides this one by ruling out conflicting suggested 
specia Iizations. 

Basic device types are just canned diagrams; the choice is which version 
of essentially the same circuit to take. That is why these special cases can 
be distinguished. In choosing among superordinate devices, rules for zeroing 
in on basic sub-types are entirely up to the user. 

(2) [ACQUIRE | dev ice type|] «> [<|name|>] 

MAKE a device type, unless there is already one around which can be used. 
<*ACQUIRE-D0-1, ACQUIRE-00-2> For example, you should always re-use old 
voltage sources instead of making a new one; you should never re-use a 
transistor; and you should look around to see if you can bum a node before 
making a new one, (This last information is purely domain-dependent. See 
Appendix 3.) 
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(3) [EXPAND |device|] 

This action is required for devices which are not fully specified by their 
circuit diagrams. (See below. Sect. III.A.2.) This task doesn't require 
elaboration, but accumulates subtasks by deduction. For example, it picks up 
expansion obligations from composite device schemata. These are actions which 
become subtasks of the task of EXPANDing each instance of the device. 
<*EXPANSI0N-0BLS-D0> Other tasks that are created involve finding all GENERIC- 
CA’s of the device that have been constrained and deriving the formulas which 
define them. «*GENERIC-CAS-DO> (See Sect. IV.B.4.) 

(4) [CONFIG < -types- > 

(X (-vars-) < -actions- > )] 

This is a "macro-action" which is an abbreviation for "ACQUIRE the types, 
then bind the vars to the resulting devices to generate a list of actions to 
perform." <*CONFIG-DEFN> The LISP program SET-UP-CONFIG which elaborates it is 
not shown in Appendix 2. CONFIG is used as an abbreviation in Appendix 3. 

III.B.3 Constraints 

(1) [CONSTRAIN < -quantities- > |pred|] 

Executing this action commits the interpreter to making pred hold true of 
the various physical quantities and control quantities. Thus, it is naturally 
a policy. CONSTRAIN is a peculiar mixture of ACHIEVE and ASSUME. If a 
quantity is under control, you are permitted to ASSUME it has any value that 
doesn’t contradict what is already known about it. So, when CONSTRAINing, it 
is often permissible to record any equalities deducible immediately from its 
constraint plus other constraints and equalities to be found in the data base. 



Ill Design of Hierarchical Systems 


115 


(Cf. (Sussman and Stallman, 1975).) If these constraints and equalities 
contradict the new constraint, the action fails. (See Sect. IIl.B.) 

In detail <*C0NSTRAIN-D0>, this is how CONSTRAINing is done: if the number 
of unknouns is exactly one, and the main connective of the constraining 
predicate is then the system is to try to solve the equation 

immediately. <#CONSTRAINT-RESOLVE-DO> If it is solvable, the result is to be 
protected. (See belou.) In either case, the CONSTRAIN remains an established 
policy (a "constraint"). 


Algebraic Symbol Manipulation 

Several times in discussions of constraint and equality manipulation I 
have assumed some sophisticated symbol-manipulation ability by the program. 

The various tasks that I take for granted include solving equations, choosing 
values to satisfy rather arbitrary constraints (including inequalities), and 
finding the precise way that a one control quantity depends on the variation 
in another (see Sect. IIl.B). In the long run, it would be enlightening to 
see whether the structure of the NASL system is sufficiently flexible for this 
information to be encoded as a set of NASL formulas. Preliminary indications 
are that this is quite feasible; very simple equations are already solved by 
the tasks generated by <*EQN-S0LVE-D0>. (Other equations might be handled by 
the methods of (Bundy, 1975).) My judgment has been that to explore this byway 
in more depth would bog me down. This decision is not obvious; after all, 
flexibility of app I i ca t i on i s one of the ma in des i gn goa Is of my system. 
However, having an implementation of one domain is, for now, much preferable 
to having curious fragments of several. Therefore, I depend upon calls to an 
expert symbol-manipulation system to do this work for DESI. I might have used 
some symbol-manipulation system like MACSYMA (Mathlab, 1974), but. for 
simplicity, I chose myself as this expert subsystem. Whenever a non-trivial 
symboI-manipuI ation problem needs solving, the system types out a request for 
a solution and waits for its human interlocutor to supply it. 

It is to be hoped that this is not a permanent trend in computer science, 
since it tends to reverse the usual practice of having humans do the creative 
work while machines do the tedious chores. 
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(2) tSELECT-VALUE (control attributel (primitive device|3 

This action is to be postponed until all tasks of Types 1, 2 and 4 are 
finished. <*SELECT-POSTPONE> DESI makes all SELECT-VALUEs subtasks of a task 
SELECT-EM-ALL which is a successor of every "topology-changing task." It is 
assumed that this kind of task is recognizable from its action function. 

(MAKE and FIX (-quantity) are the only built-in topology-changers.) 

When the system gets to a SELECT-VALUE task, either the control attribute 
for this device already has a value; or DESI must pick a value within the 
range of the control attribute uhich fits all the known constraints on it 
<*SELECT-VALUE-DO>, and impose model effect 

[-/> ’(|control attribute! (primitive device|) |value|). 

It then PROTECTS the fact that the value satisfies the constraints. 

If there is no such value, the system is faced with a "constraint 
collapse" (see Sect. III.B); that is, it has made a mistake. 

Executing SELECT-VALUE tasks causes the resolution of all remaining 
constraints of a network. 

(3) (PROTECT *(proposition)] 

The intent of this action is that the system should become alarmed, i.e., 
realize it has made a mistake, when the fact is no longer true in the model. 
This is not as easy as it sounds or as it is usually implemented (Sussman, 
1975), because the given fact may be only indirectly related to atomic facts. 

Because data dependencies are maintained by the system, it might be 
possible in principle to make this a built-in action. That is, the system 
could just wait for propagating erasures to wipe out a fact. Something 
special would have to be done for the results of non-monotonic inference (that 
is, using /: CONSISTENTLY), because in this case it is recording a fact that 
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could upset the protected fact. 

For this reason (and for the weak introspective reason that protection 
does not seem to be a fool-proof operation), I have DESI treat protection as a 
problematic action to be reduced to different subtasks in different cases. 

This decision is under review. 

In the design domain, we have need primarily of protecting values which 
are derived from consideration of constraints. This is done <*QVAL-PROTECT> 
by /sMONITORing the fact that the quantity has a value and /sCONTINUing the 
protection policy when the value is removed. <*PROTECT-CONTINUE> 
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Figure 111.9 Quantity-Value Protection Plan Schema 
Notice that the variable may be getting a new value which satisfies the 
constraints, so the system cannot jump to the conclusion that a protection 
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violation has occurred. The decision to continue the policy is generally 
postponed. Upon continuing it, if a violation has occurred, DESI realizes its 
mistake. 

III.B.4 Changing Devices 

This is a catch-all category which includes biasing, feedback, coupling, 
and fixing the value of a physical quantity. These actions are described in 
the next chapter. Other domains would have other actions. 

The last action in this list is the only one I feel there is anything to 
be said about at the rarefied level of general design. Even for that one, 
about all that can be said is that, for almost any domain, there exist ways of 
fixing physical quantities, bringing them under control, creating "boundary 
conditions." For electronics, this is done with sources, voltage dividers, 
etc. In mechanical engineering, it might include fastening things down, 
hooking up motors, etc. Perhaps it is worth saying that "Fixing a physical 
quantity means turning it into a control quantity," but I’m not sure how to 
say that. It is likely that the way one’s knowledge of this sort of 
regularity is used is in assimilating a new domains namely, everyone knows 
that when he is learning about meta-hydraul ic engineering he should be sure to 
ask what methods there are for fixing meta-hydraulic quantities. 

Besides these actions, which arise in the course of normal problem 
solving, there are actions (subsumed under "patch" in Fig. 111.6) required to 
change a circuit because it is failing to meet its specifications. These are 
described in Sect. III.D; they are not implemented, because the mistake- 
correction machinery to support them does not exist. 

Many design plan schemata are arranged in specialization hierarchies 
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similar to hierarchies of specialized composite device types. (Sect. 111.A) 
This is especially true of the circuit-alteration plans discussed in the next 
chapter. The reason for this is that a circuit-alteration plan for an action 
like "bias ..." is close to being a device type. The difference is that the 
procedural component is larger and the plan is more anonymous; the resistors 
used for biasing do not become components of a "biasing device," but of the 
circuit that is being biased. 

Just as devices may be related by the predicate SPEC-DEV-TYPE, plan 
schemata may be related by 

(SPEC-SCHEMA |plan schema 1| |plan schema 2|1. 

Any instance of the specialized schema (1) is an instance of the general 
schema (2). <#SPEC-SCHEMA-DEFN> Choice rules are provided for these plan 
schemata which are completely analogous to the rules (Sect. III.B.2) for 
choosing among specialized device types. <*SPEC-IS-BETTER, TUO-SPECS-UDRSE- 
THAN-ONE> 

Two other useful control predicates defined in the file DESI are STASK 
<*STASK-DEFN> and REDUCE. <*REDUCE-DEFN> The first is used to abbreviate in 
the common case where a task is defined, and made a subtask of something else, 
in the same breath. The second is used to express a common interaction among 
design plans: when one plan accomplishes part of the function of another. In 
that case, saying [REDUCE < -reducers- > |reducee|] means "the reducer tasks 
are all the subtasks of the reduces task; don’t bother to try to execute it 
any further." (Cf. Sect. II.B.l.) 
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III .C Composition of Partial Solutions 

One of the most interesting and complex events that can happen during the 
career of any problem solver is the failure of the labels attached to its 
canned plans to match all of the requirements of some task. In a design task, 
this situation atlous unlimited scope for the study of creativity. Of course, 
our knowledge of such matters is as yet very slight, so that the approach my 
system takes to the handling of such problems is not terribly brilliant. 

When a DESIGN task does not immediately succeed, an attempt is made (Sect. 
III.B) to break it down into a core task plus several constraints and 
"features." For example, the knowledge in ZORCH is sufficient to discover 
that an amplifier is required given a wide range of requests for designs. 

Then further choice information from ZORCH is used to select one that is 
likely to meet all the amplifier constraints so generated. As mentioned in 
Sect. II.A, this sequence is called the "recognition protocol." Finally, the 
constraints are resolved. 

Often this approach fails. It may fail in more than one way: 

(1) More than one "core device-type" (see Sect. 111. A) may be discovered. 

(2) There may be more than one way to implement a core device type. (See 
above, especially the discussions of "superordinate" device classes and 
abstract device-types.) 

(3) The constraints generated may not actually be satisf'table. 

All of these problems may call for composition of solutions to subproblems. 
The last problem is peculiar in some ways: I devote section 111.D to 
describing constraint resolution. 

The others are related by having to do with the choice protocol. For 
example, problem (2) may arise if more than one amplifier fits some of the 
requirements, and none fits well enough to exclude the others. In this case. 
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the response of the system uhen no further exclusions can be made is to record 
[QUIESCENCE (choice name|] in the choice data pool. 

It is here that choice rules uith conclusions of the form t/sRULE- 
TOGETHER...] are important. They allow options to be superseded by new 
options. This is the most natural and painless place for composition to occur 
in a NASL-based system. 

This is the closest DESI comes to a universal composition method. Thi 3 is 
a defect in the system as it exists. A better system would recognize the need 
for a /:RULE-TOGETHER and propose one; future episodes would exercise and 
modify it. For example, some of the choice rules for amplifiers discussed in 
the next chapter contain almost-general principles regarding cascading a 
buffer amplifier to another amplifier when the first was picked for its input 
impedance. It is not hard to see a more general principle regarding inputs 
and outputs lurking behind this specific one. It lurks there still. 

For nou, you must be content uith the specialized composition rules in 
Chapter IV. 

111 - 0 Constraint Collapse 

As a design proceeds, the current data pool fills up with formulas 
specifying components, connections, quantity values, and constraints. If 
everything proceeds smoothly, eventually there will be a value for every 
primitive component and the problem ui 11 be solved. The most common thing to 
go urong uith this scenario is to discover that some subset of constraints 
cannot be satisfied. DESI counts this as a mistake in the sense of Sect. 

II.E. All its previous machinations were based on the assumption that the 
functional requirements could be reduced to constraints and satisfied. When 



Ill Design of Hierarchical Systems 


122 


this turns out not to be the case, the task network must be altered to reflect 
what it should have been doing. On the other hand, as much as possible of the 
network must be salvaged. 

As I pointed out in Sect. II.E, my theory of mistakes is as yet poorly 
developed. This section must be taken as a continuation of the detailed 
proposal I made there, not as a description of existing program. 

As a concrete example, say that a low-pass filter is required, which 
filters out one radio station at 700KHz to leave the signal of another, 
equally strong station at 500kHz. 


I KEEP FLUSH 

WA* 

500 700 

Figure 111.10 Radio Spectrum With Two Stations 
This problem can be represented easily using the "frequency picture" language 
I will develop in Chapter IV. I will continue to use simple English in uhat 
follows. 

The chosen solution 19 an RC low-pass filter, an instance of the schema 
represented by Fig. I.G. This schema and the frequency-domain methods used to 
find it (Sect IV.B.l) generate these constraints and equalities: 
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CONI (from rephrasing of the problem): 

V q (700 kHz) < .1V Q (500kHz) 

C0N2 (from schema for RC filter or by analysis): 

H(s) - 1 

1+RCs 

C0N3 (from knowledge of filters): 

selectivity^, ■ |H(j2nfj)| 

|H(j2nr 2 | 

C0N4 (from knouledge of linear devices): 

|H(j2nD | - V f) 

V f (f) 

Figure III.11 Relevant Constraints 

From these constraints and the statement of the problem, we can build 


the following "constraint network ": 
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C0N2(fl) CON2(f2) 


C O N 4 (fl) 



CONI 


Figure 111.12 Constraint Network 
(Cf. <*CQ-CL0> in Appendix 2.) 

If all the constraints are satisfiable, that is, if the output amplitude 
ratio can be made small enough that the second station has negligible output 
compared to the first, everything is fine. But, as it happens, there are no 
values of R and C which can be picked in order to bring this off. This is 
referred to as "constraint collapse." This will be noticed when one of the 
constraints proves unsatisfiable. Uhich constraint it will be is 
unpredictable; the problem is clearly a problem of the whole netuork rather 
than any task. 

Recall from Sect. II.E that fixing a mistake involves altering the current 



Ill Design of Hierarchical Systems 125 


world model and the task network. In this case, there are several current 
tasks that have caused the problem: the choice of an RC circuit to implement 
the low-pass filter, and the various CONSTRAINS, some thawed from the RC 
schema, which led to the trouble. DESI has a record of every choice it made 
in the process of setting this network up, so it could find a choice point 
that would make a difference, restore the state of the world at that point, 
and try something else; I have already discussed and rejected this in Chapter 
II. 


The design knowledge of DESI provides us with a better method of solving 
this problem. This method amounts to the following English summary: 

(1) Find a control-quant i ty in the collapsed task network such that 
changing it would get rid of the problem. This is not as easy as it sounds. 

It is counterproductive to consider "making V 0 (500kHz) larger." for instance. 
Any method for doing that will probably make V 0 (700kHz) larger as well. In 

the example, the proper answer is "selectvity." I assume symbol manipulation 
powerful enough to handle this. (Sect. III.B.3) 

(2) Introduce a new task (IMPROVE ’ | losing control quantity| [direction 
end magnitude|]. A task of type IMPROVE, unlike previous controI-quantity 
manipulators, has the aim of changing some already-set object rather than 
fixing one that has yet to be set. To execute the IMPROVE task requires some 
domain-dependent rephrasing, choice, etc., which by now are routine. By one 
route or another, a plan like that of Fig. 1.7 is recovered. 

(3) The actual tasks associated with the IMPROVE plan perform the 
acquisition and insertion of the new pieces, an amplifier, capacitor, and 
resistor, and the renaming of the output port. The resulting change in 
topology flushes the old constraints on the system function and hence the 
selectivity of the device and enables the design to be completed. This is not 
too painful, since the control-quantity t(H ?DEV) ?F] is marked GENERIC-CA in 

1,1,2 ’* a pool; when the old stored value is flushed, a task is enqueued to 

recalculate it. 

Except for the initial symbol manipulation, this seems fairly simple; the 
IMPROVE task is no different from any other task, such as BIAS or COUPLE, 
which alters the topology and part names of a circuit. The difference, of 
course, is that the policies associated with the IMPROVE plan must specify 
exactly what parts of the old task network encircling the RC filter are to be 


n 
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preserved. The difficulty of implementing this scheme revolve around the 
careful undoing of protections and other policies. 

III.E Programmer’s Guide 

DESI is a skeletal theory of design within which the user’s domain- 
dependent rules operate. These rules will fall into three classes: rephrasing 
rules, device definitions, and device-choice rules. 

The user’s rephrasing rules can be very simple. Any declaration that a 
function is a CONTROL-ATTRIBUTE will cause the cq-shard machinery to turn a d- 
shard of the form (IX (X) (» (|attribute| ?X) |value|)J] into a side-task to 
CONSTRAIN the given control quantity. 

More complicated rules can create entire inferential subtasks to make 
finer discriminations. Examples will be given in the next chapter. 

In making up device schemata, the user will have to use his intuitions. 
Superordinate device types are convenient slots to put inheritable 
characteristics into. A basic device type is one with a "diagram" common to 
every member of the type. (I assume that every domain DESI is likely to be 
applied to ui I I have the concept of diagram.) The "diagram" (device schema) 
wilt not be attached to the basic device type directly: instead, each node in 
the DERIVED tree below the basic type (see Fig. 111.5) will have its own 
schema. (Remember that the details of the diagrams for a device type and one 
of its specializations are likely to be inconsistent; the task networks of the 
two will be related via the SOUL device.) 

In writing choice rules, the user has a certain amount of freedom. There 
are three stages in picking a device type or design plan: deducing 
possibilities, running choice rules before QUIESCENCE, and running choice 
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rules after QUIESCENCE. (See Sect. II.C.l.) There is as yet no iron-clad 
semantics for uhat each of these stages means, mainly because I lack 
experience in interfacing rules. 

Typically, the "possibility" rules are very lax; if a device could be 
appropriate, given some piece of the current situation, some rule should 
suggest it. Throning it away or incorporating it into a larger structure is 
the job of the choice rules. (Cf. CHOOSE-AHP, in Appendix 3, described in the 
next chapter.) 

The user should be careful in his use of /:RULE-0UTs if this is the 
structure he chooses. If there are two relevant variables in a situation, and 
one is, strictly speaking, incompatible with a suggested device or plan, thi 3 
is not necessarily a reason to rule it out. After all. it would not be a 
living option in the choice protocol if the other variable had not caused it 
to be suggested. For example, input-impedance considerations may suggest a 
common-collector amplifier, while gain considerations suggest something else. 
It is clearly silly to throw away the common-collector suggestion on the basis 
of gain. Instead, a /;RULE-TOGETHER is probably appropriate. 

/:RULE-OUTs are useful mainly as a device for expressing "differential 
diagnosis information. Such a rule mentions tuo or more options, and throws 
one of them away. Remember that the order of examination of these predicates 
is /:RULE-OUT, then /:RULE-IN, then /;RULE-TOGETHER, and that the choice 
protocol qui18 as soon as fewer than two options remain. 

QUIESCENCE has no fixed meaning. Sometimes the system uses it to express 
rules which are intended to take over if the user’s rules can’t make up their 
minds; this is the case with the rules for choosing among SPEC-DEV-TYPEs. 

(Sect. III.B.2.) This freedom probably represents a deficiency in the choice 
machinery. 


rr 
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IV Electronics 

Electronics knowledge falls naturally into three categories: the physics 
and mathematics of electronic components, devices, and signals: the knowledge 
necessary to do design, including rephrasing, composition, and patching; and a 
catalogue of circuit diagrams and plans. 

In this chapter as in the last, the notation <#rormu1a-name> is a 
reference to a formula in the appendices, in this case usually Appendix 3. 

This Appendix is rather long, but has been laid out in an order which 
corresponds as closely as possible with the presentation of this chapter. 

This chapter is fairly dull. Given the vocabulary and conventions developed 
in Chapter III, it is routine to encode much of the information I will 
describe. 

Appendix 3, long as it is, can only be described as "sketchy." For each 
important concept I will discuss, there is a representative circuit, plan, or 
rule set in the appendix, but often several of its siblings will be missing. 

I will describe these gaps in Sect. IV.D. 

IV.A Physics 

IV.A.l Connections and Constraints on Components 

Recall from Chapter Hi that connections in a design domain are physical 
configurations associated with constraints. In electronics, these 
configurations are called nodes. 

Interfaces betueen electronic devices are of two types: terminals and 
ports. I will discuss ports later. A terminal is a wire coming out of a 
primitive or composite device. A group of terminals may be bunched into a 
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"node." One constraint on a node is "Kirchhoff’s Current Law" (KCL) (Senturia 
and Wedlock, 1975), which says that the sum of the currents into a physical 
node is zero, fly "logical" nodes are treated as terminals themselves at a 
higher level," where they may themselves be joined into nodes. <*N0DE-TRf11 N> 
(See Fig. IV. D.) KCL for nodes therefore states that the current into the 
node, considered as a terminal, equals the sum of the currents out of the sub- 
terminals defining the node. <*KCL-2> 



Figure IV.1 Terminals and Nodes 

Devices also satisfy Kirchhoff's Current Law. <*KCL-1> A composite device’s 
terminals are almost always nodes themselves. These will be declared with the 
predicate DEV-TERflINALS. <*KCL-3> (Fig. IV.2) 
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L_J 

(dev-terminals d* 


< (N1 D*)(N2 D*)> 


Figure IV.2 Composite Device Terminals 
A fundamental model manipulation in the electronics domain is to merge two 
nodes, which makes them equal. <#N0DES-f1ERGE-riANIP> A less easily visualized 
operation is DEV-INSERT <*DEV-INSERT-riANlP>, which breaks a node in two. 

(Fig. IV.3) 



Figure 


(DEV-INSERT D" N 
<(#1 D*)>< T2 T3 T4> 
<(#3 D*)>< T1 T5>) 



IV.3 Inserting a Device 


T3 



into a Node 


Ports are pairs of terminals (which are almost always nodes of composite 


devices), to be thought of as carrying signals. The signals may be 









IV Electronics 


131 


implemented either as currents or voltages. <*P0RT-TAX0N0I1Y> A set of voltage 
ports may be grouped into a nest, which is exactly analogous to a node formed 
by grouping terminals. (In particular, every nest is considered a higher- 
level port.) <*NEST-PORT> Ports may be combined into nests, and nests may be 
merged, just as terminals are combined into nodes. <*NESTS-MERGE-MANIP> 



Figure IV.4 Ports and Nests 


Kirchhoff also had a voltage law, which for our purposes merely amounts to 
the fact that every point in space can be assigned a conventional voltage. To 
enforce this, the rule <*KVL-1> constrains all the node and terminal voltages 
at a physical node to be the same. 

All devices are given interface descriptions by the packets defining their 
device types. The interface description (e.g., "?X is a 2-terminal") interact 
«ith formulations of Kirchhoff's voltage and current laws to generate standard 
constraints. <*2-TERMINAL-DEFN> Composite device types (see Chapter III) may 
have terminal or port interfaces, or both. 

An important class of devices are the "signal transmogrifiers" or SIG- 
TRANSERS, by which I mean any device one of whose primary functions is to take 
a signal in on its input port, or "INPORT," and put out a signal on its output 
port, or "OUTPORT." <*SIG-TRANSER-GL0RIA-f1UNDI> 
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(Much of the notation in this and the following section has been 
influenced by the notations devised by A. Broun (1975) and Stallman and 
Sussman (1376).) 

IV.A,2 Signals 

Signals are abstract objects with three components: a time function, a 
signal-medium (voltage or current), and a "home" (a port). "A signal is any 
physical variable uhose magnitude or variation uith time contains 
information .... Uhen we speak of ‘signals,’... we refer ... to voltages and 
currents." (Senturia and Uedlock, 1975, p.2) 

A "homeless" signal is not allowed in my notation. A signal may have more 
than one home, but only if all its homes are in the same nest. <*KVL-2> 

Given a port, the function PORT-SIGNAL should give its signal. 

To make up for the absence of homeless signals, many actions manipulate 
signal descriptions, lambda-expressions from signals to truth values. For 
example, the formula 

{CONVERT Jdevice| |signal description! |signal relation!! 
means "device converts any signal appearing on its INPORT which satisfies the 
description into an OUTPORT signal which bears the relation to the input 
signal." An example of the use of this predicate appears in Chapter I. 

Another is. 
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[DESIGN (X (X) 

(CONVERT ?X 
(X (SI) 

(FORALL (F) 

(IMPLIES (/> ?F 1MHz) 

(- ((FOURIER-TRNSFRM (TFUN ?S1I) ?F) 

0 ))) ) 

(X (SI S2) 

(FORALL (F) 

(AND (IMPLIES (/< ?F 100kHz) 

(- ((FOURIER-TRNSFRM (TFUN ?S2)) 

?F) 

0 )) 

(IMPLIES (/> ?F 100kHz) 

(- ((FOURIER-TRNSFRM (TFUN ?S2)) 

?F) 

((FOURIER-TRNSFRM (TFUN ?S1)) 

?F))))) )))] 

This formula illustrates the use of the Fourier transform of a signal. 

The DESI+ZORCH system actually lacks any deep mathematical understanding 
of transforms. Instead, it summarizes the frequency-domain behavior of a 
signal with a frequency picture of its time function. A frequency-picture is 
a tuple of "frequency features." A feature is specified as (FF |freq| 

| Iandmark11. <*FF-FREQ, FF-LANDMARK> A landmark may have a shape, height, and 
width, written FL-SHAPE, FL-HEIGHT, or FL-UIDTH. In general any particular 
characteristic is optional, but the assumption is that a feature has non-zero 
size. These are similar to the human conventions for such descriptions. 

Signal characteristics can have these values: 

SHAPE — may be SPIKE, HUMP 

WIDTH — a HUMP may be SHARP or FUZZY 

HEIGHT — a number 

The notation [SERIES |freq| |delta freq| |shape| |fun|l defines an 
infinite frequency picture consisting of a row of features of the given shape, 
at interval of delta freq, starting at the given frequency. The height of the 
nth landmark in the row is given by fun. This function must be decreasing (as 
it will be in all physical applications). 


n 
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(Thi9 way of reasoning about the frequency domain '13 in many ways closer 
than straight Fourier transforms to the way humans think about it, and reveals 
more about the signals. Thi9 is a good illustration of the point that using a 
logical notation does not commit you to a "mathematical" treatment of a 
domain.) 

For example, a square wave of frequency f offset by half its amplitude 

has frequency picture picture 

[< (FF 0Hz LANDMARKS) 

MISERIES |f| (* 2 | f |) 

SPIKE (A (N) (* |A| (// 4 (* ?N PID) ))>] 

where 

[FL-SHAPE LANDMARK#79 SPIKE! 
and [-/> ’ (FF-HEIGHT LANDMARKS) (// Ml 2)1. 

The usual graphical notation for the Fourier transform of an offset square 

wave 19 , of course. 



Figure IV.5 Fourier Transform of an Offset Square Wave 
Time-domain signal attributes are also known to the system. A function 
may be periodic with a certain period, expressed as [PERIODIC |tfun| 

|period|!. If so, [ONE-PERIOD |tfun|) is a function which is zero everywhere 
except from -T/2 to T/2, where [(ONE-PERIOD } tfun|) ?T! - [11fun| ?T! . (T is 
the period of the function.) Others are (following (A. Brown, 1975)) the DC 
offset of the signal; ampTItude, the height of a periodic signal; phase with 
respect to another signal; etc. 
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A large set of formulas is concerned with computing the frequency picture 
of periodic signal descriptions expressed in time-domain terms. <*PERI0DIC- 
FREQ-PIC> 

Besides these intrinsic descriptions, there are "extrinsic" signal 
properties like "carrier," or "modulation," or "distortion." These concepts 
would be necessary for a system that designed or redesigned radios, which are 
a level above that which I have focused on. (This is the chief difference in 
emphasis between Brown’s approach to signal description and mine.) It appears 
to me that it would be easy and instructive to add this knowledge to DESI, but 
that it would be a slight detour. 

Of course, the descriptions of Signals are of interest only so far as they 
support comparison. Ue are interested in designing circuits which convert 
from one kind of signal to another; given two pictures, a good description of 
the transformation from one to the other will help U 9 to retrieve useful 
plans. This will be described below, in Sect. IV.B. 

IV.A.3 Multiple Models of Linear Systems 

A great advantage of a linear domain such as elementary electrical 
engineering is that it may be profitably attacked by linear, time-independent 
methods in many cases. In addition, the fact that analysis is of a closed 
network makes a forward-deduction scheme practical. (Cf. (Nevins, 1974c, and 
Sussman and Stallman, 1975).) 

The folowing types of quantities are to be dealt with by an electronics 
analyzer (see Sect. IV.C): 

physical quantities like voltages and currents 

component control quantities like resistances and capacitances 


II 
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The kinds of questions to be answered are: 

What is the the value of some physical quantity in a given circuit? 

What are the values of derived control quantities like the Thevenin 
resistance or gain of a circuit? 

Often these questions are with respect to a circuit of interest as given, 
but just as of ten expl ici t or implicit reference is made to a derived model of 
a circuit. For example. 

The DC gain of a circuit is the gain of the DC model of that circuit 

The Thevenin resistance of a circuit is the resistance of the circuit uhen 
it is disconnected from its environment and its independent sources are set to 
zero. 

The impedance of a circuit is its (complex) resistance in its "sinusoidal 
steady state" model. 


These models are generated by the use of FRAME, N, and T formulas (see 
Sect. II.B.2) in the data base. Many of these appear in the schemata for 
various devices, but the FRAME axioms occur separately. Together they define 
the models as follows: 

(1) [(DC)) The DC model of a circuit is the same circuit with all frequency- 
dependent features nulled in a device-dependent way. Thus we have <*FRAME-OC> 
plus formulas I ike 

[IMPLIES (IS CAPACITOR ?X) 

(AND (N (DC) MIS CAPACITOR ?X)) 

(T (DC) (IS OPEN ?X)))] 

(cf. <*CAP-PKT>) for frequency-dependent components like capacitors. The (DC) 
of an already-DC model is itself, because these components can be nulled only 
once. <*DC-I0EM> Thus (see Chapter II), we have 

[N (DC) MT ?R (FRAME (DC) <(HERE)>))3 
IT (DC) (-/> ’(DC) (HERE))) 


(2) KINO) The incremental model of a circuit. <*REF-INC, FRAME-INC, INC- 
IDEM> 
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(3) [SSS |s|] The sinusoidal-steady-3tate model for complex frequency s. 
<*REF-SSS, SSS-IDEM, FRAriE-SSS> (In this model, all linear devices act like 
resistors with complex resistances or impedances.) 


(4) [ISOLATE |trmin 1| |trmin 2|J The model obtained by disconnecting the 
given terminals from whatever nodes they appear in. <*IS01ATE-DEFN-1, 2, and 
3> (These terminals are usually nodes in a composite device.) It is used for 
calculating Thevenin resistances. <*REF-IS0, FRAME-ISO, IS0-IDEM> 


(5) [PASSIVE! The network with all active sources set to zero. Also used for 
calculating equivalents. <*REF-PASSIVE, FRAME-PASSIVE, PASSIVE-I0EM> 


IV.B Electronic Design Knowledge 


The knowledge in ZORCH is meant to mesh with the knowledge in OESI so as 
to bring about useful behavior. Generally DESI provides the plan framework 
and some quite general heuristics, while the solid stuff is in ZORCH. This is 
true of knowledge about design actions. 

IV.B.l Rephrasing Electronic Design Problems 


When it comes to rephrasing design, DESI does little more than provide the 
concept of "d-shard" and the policy that every shard in the initial explosion 
must lead to something useful. (Chapter III) Most of the knowledge is in 
ZORCH. Here are defined the interesting control quantities of thi 3 domain: 
voltage gain <*V-GAIN-SHARD>, and input and output impedance <*INPUT-Z-SHARO, 
OUTPUT-Z-SHARD>. These lead to side-tasks which constrain control quantities 
(vfa <*CQ-SHARD> in DESI), but they also lead to domain-dependent "d-features" 
regarding the ranges of these quantities. These all end up affecting the way 
in which device schemata are selected. 

Besides this sort of control-value redescription, more devious things can 
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happen. If a d-shard of the form [(X (|v|) (CONVERT ...)]] appears in the 
middle of the explosion, it causes an inferential subtask to appear. «;*CVT- 
EXPLODE> This subtask mimics the supertask for exploding design properties, in 
that it manipulates formulas describing signals, breaking them into "signal 
shards." These signal shards are then parsed into d-shards and ultimately 
into d-features, side-tasks, and core device types. 

There are tuo complementary paths this deduction can take. One <*FREQ- 
DOM-REPHRASE> tries to compute the frequency pictures of the input and output, 
then find a transformation ("FREQ-PIC-TRANS") between them. The output of 
this deduction is an object of the form [LOU-PASS |cutoff|I, [HIGH-PASS 
|cutoff|I, [MODULATE |freq|], etc. This transformati on becomes a signal 
shard. This language for describing frequency transformations is not as 
general as it could be. On the other hand, it is quite extensible, and 
reflects everything I know about the subject. 

The other rephrasing method <*TIME-DOMAIN-REPHRASE> merely searches for 
certain simple functional relationships between the time values of the input 
and output. (This has not been implemented yet.) 

The system tries to choose <*CVT-CHOICE> between these two ways of 
rephrasing on the basis of simple criteria. For example, if the input 
predicate to CONVERT doesn’t mention the input at all, the transformation is 
more likely to be a function of signal values, so the time-domain is ruled in. 

IV.B.2 Reconciling Partial Solutions 

This kind of information arises in two places: generating and choosing 
core device-types, and choosing ways of making devices. (As in Sect. II I.D, I 
am not including information about patching failing constraints.) 
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It 19 important to note that computation regarding a circuit is to be 
postponed whenever possible until after the design rephrasing plan. This '19 
because (a) the ideological intent is for this phase to be concerned with 
problem, not solution, manipulation; and (b) the pieces of problem are lying 
around in the wrong form to be noticed during deductions. 

So, during the d-explosion and subsequent re-parsing, DESI is more 
interested in seeing the pieces than putting them together. This orientation 
means that ordinarily the generation of tuo core device-types 19 an error; the 
error will be revealed by the choice protocol for the CORE-FINDER step of Fig. 
III.7. 

ZORCH makes up for this by allowing the design rephraser to pass the buck 
under certain circumstances. <*L I NEAR-GROUP I NG> If one of the competing core 
device types is linear, ZORCH rules them together into the artificial device¬ 
type [GROUP < -device types- >]. GROUPing means CASCADing in some as yet 
undetermined order. <*MAKE-GR0UP-1, MAKE-GROUP-2, MAKE-GR0UP-3> The idea is 
to postpone deciding among them or composing them until the constraints and 
features have been sorted out. After all, you can be pretty sure a linear 
device will not interfere too badly with what it is connected to. 

("Cascading" two dev ice-types means making one of each and coup I ing them. See 
below.) 

This is the somewhat bedraggled method by which core-device-type choice 
can give rise to cascades. This should be a rare event. Normally, the device 
classes introduced do their job harmoniously enough 90 that one superordinate 
or basic category i9 natural for describing a desired circuit. In that case, 
the category will wind up as part of the central MAKE task of a design 
network. (See Fig. 111.8.) Here cascading will reappear in a much more 
disciplined way as the choice of which subordinate or specialized device type 
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to use. 

In choosing a May to MAKE a knoMn circuit type such as an amplifier, often 
more than one suggested subtype comes to mind. This will be because various 
subtypes are indexed by associated D-NOTES. <*M0Q-V-GAIN, HIGH-V-GAIN, etc.> 

If more than one device is triggered by a constellation of D-NOTES, it may be 
for two standard reasons. First, a control quantity like gain may fall into 
two ranges. (<*V-GAIN-SHARD> and its ilk specify overlapping ranges, for 
example.) If so, a value falling in the ambiguous region may necessitate 
differential diagnosis in the subsequent choice situation. One might have to 
decide between an op-amp or common-emitter amplifier on the basis of cost, 
convenience, etc. 

Second, the two suggestions may answer to different subrequirements, in 
which case they must be combined in some way (or one subrequirement must be 
foregone). 

Rules for performing these functions for the device type AMPLIFIER are 
given in the packets defined by <*CH00SE-AMP>. This contains principles like, 
"If high banduidth is required, prefer a multi-stage amplifier to a single 
high-gain stage"; and, "If one option (e.g., a common-collector) has been 
proposed because of its input impedance, and another for some other reason, 
cascade them in that order." 

The fact that in using the rules of <#CH00SE-AMP> the system is restricted 
to a well-defined situation helps to make those rules concise and to the 
point. This attests to the organizing power of the concept of "superordinate 
device type." It is difficult to think of a natural choice situation in which 
the statement of the problem does not bring to mind a set of rules organized 
around some such type. It appears that a large part of the training of 
technicians and engineers is the accumulation of these sets. 
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Cascading two device types is MAKE-ing an object of the abstract type 
[CASCADE | type 1| | type 2|J. <*f1AKE-CASCADE> This consists of a 
straightforward plan to MAKE a device of each type and COUPLE them. The 
components of the result are the two devices. In cascading two device types, 
it is wise <*C0UPLE-GENERAL-1, COUPLE -GENERAL-2 > to use the most general 
specializations of the device types involved. These are defined by the 
predicate MOST-GENERAL-SPEC (defined in Appendix 2). An example is the device 
type GENERAL-CE, which is the most general common-emitter circuit. 

Coupling comes under the heading of a circuit-change operation. (Cf. 

Sect. III.B.4) 

IV.B.3 Changing Circuits 

Except in the dullest circumstances, a circuit schema cannot be 
instantiated merely by binding a few variables. After it has been plugged in, 
its expansion obligations" become active. (In the case of a productive 
device type like [CASCADE ...I, these obligations are part of the plan that 
makes a device of that type.) These expansion obligations are the normal 
place in which circuit-changing tasks arise. (If failure-correction were 
implemented, this uould also be a common source of circuit changes, of 
course.) 

The circuit-changing actions defined so far include biasing, coupling, and 
fixing voltages. These actions come in specialization hierarchies, and they 
interact in interesting ways. 

Biasing bipolar junction transistors (BJTs) is defined by <*BJT-BIAS-NET> 
3s three important tasks: fixing the collector current CIq), reverse-biasing 
the col lector-base junction, and fixing the base-emitter voltage (Vg^). For a 
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typical one-stage transistor amplifier, these tasks are subsumed by the 
specific suggestions in <*TYPICAL-BJT-ONE-STAGE-BIAS-PLAN>. 
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Figure IV.B Bias Plans 

This plan defines the bias networks of Fig. 1.2. 


The biasing plan interacts with the coupling plan for BJTs <*COUPLE-NET>, 


which itself has several SPEC-SCHEMAs. The general plan is shown in Fig. 


IV.7. 
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TYPE 

Figure IV.7 General BJT Coupling Plan 


The interaction starts with the rule that coupling is considered before 
biasing. <*COUPLE-BEFORE-BIAS> (Cf. Fig. 11.5.) The reasons for this rule 
are that decisions made during coupling often influence the way in which, 
biasing is done: and that coupling components perform many biasing functions. 
These interactions depend upon the particular coupling network chosen. The 
rule packets <#COUPLE-CE-X-HINTS, COUPLE-CC-X-HINTS> suggest particular 
subnets to be used. One of these <*CE-DIR-VOL-COUPLE-PLAN> is shown in Fig. 
IV.8. (The others are as yet unwritten.) 
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Figure IV.8 Common-Emitter Direct Voltage Coupling 
Choosing this plan amounts to settling on direct coupling with voltage as the 
medium. Picking it reduces tasks from the bias network and main coupling plan 
without further examination. 

Two plans for fixing voltages is shown in Appendix 3. <*VS-FIX-V, VD-FIX- 
V> The first is used to set voltages absolutely. The second is used for 
setting voltages, such as the base voltage of an transistor, which are to be 
allowed to change incrementally. 





IV Electronics 


145 


IV.B.4 Electronics Analysis Knowledge 

In the usual case, there is no special electronics analysis knowledge. 
Device properties are expressed by numerical constraints (Chapter III), which 
interact with each other and SELECT-VALUE tasks to produce results. In the 
ideal case, the deductions involved are always "one-step deductions" (Stallman 
and Sussman, 1976) of the value of one variable at a time. (I have taken much 
of the analysis knowledge practically verbatim from Stallman and Sussman’s 
data base.) 

Besides calculations of physical quantities and component values, there is 
also the problem of computing values of "generic control quantities" (Sect. 
III.A.l). These are quantities like "voltage gain," which is defined 
generically as, "The value of the voltage on the outport over the value on the 
inport," but whose symbolic and numerical values depend o.n the circuit 
involved. When a generic attribute value is constrained, a task will be 
created to calculate it. <*G£NERIC-CAS-DO in Appendix 2> 

How this is done depends on the quantity to be calculated. For example, 
to calculate the Thevenin impedance of a circuit from two terminals, you must 
enter the reference point (ISOLATE |trmin 1| |trmin 2|), fix the voltage at 
the two terminals, and calculate the current. (This technique is probably 
beyond the current competence of NASL. For a precise account of how to do it, 
see Doyle, 1977.) 

Very little electronics analysis knowledge has been implemented. (See 
Sect. IV.D. below.) My implementation has focussed on qualitative reasoning 
about design; it complements the work of Stallman and Sussman (1976) on 
quantitative analysis. 
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IV.C Device Schemata 

The last part of Appendix 3 is a bag of device schemata. These include 
primitive components and a few composite devices. Host of the primitive 
components are defined entirely by one or two constraints and some T and N 
formulas describing their behavior from various derived models. The 
transistor schema <*BJT-DEFN>, as you might expect, has a more complicated 
structure. Besides the physical constraints on its terminal voltages and 
currents, every transistor must be biased into its desired region. Thus, a 
composite device schema that specifies that its transistor is active will 
automatically acquire an expansion obligation to bias the transistor. 

There are several device schemata for composite devices defined at the end 
of Appendix 3: 

GENERAL-CE — The most abstract common-emitter circuit 

TYPICAL-CE — The circuit shown most often in textbooks, which is derived 
from the more abstract one 

GENERAL-ECP — The most abstract emitter-coupled pair 
ECP-DC-ANP -- One of many circuits that can be derived from the ECP 
VD — The humble voltage divider 
RC — The filter, not the cola. 

The relation betueen the ECP-DC-AflP and its "soul," the GENERAL-ECP, is 


ehoun in Fig. IV.9 
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Figure IV.9 General and Specialized Emitter-Coupled Pairs 
A similar relation exists betueen GENERAL-CE and TYPICAL-CE. In defining 
these relations, extensive use is made of the predicates REDUCE and FUNCTION, 
defined in Appendix 2. REDUCE declares that some set of tasks is a complete 
subnetwork of the reduced task. [FUNCTION |dev| |reduced task|] is a special 
case, used in device schemata, which declares the existence of an abstract 
task for acquiring the device dev, and specifies that this task is sufficient 
to accomplish the task to be reduced. 

The function 10BL |dev| |action|] denotes an expansion task created by the 
use of rule <*EXPANSI0N-0BLS-D0>, defined in Appendix 2. 


n 
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IV.D Programmer ’9 Guide 


A 9 I have pointed out in several places, the information in ZORCH is 
sketchy. I hope this hasn’t harmed the clarity of my presentations I have 
provided an example of every kind of construct I discussed. The knowledge 
shown is still in the process of being debugged and assimilated into OESI; 
there has not been time to be complete. As it is, implementation and 
debugging cannot keep up uith generation of new formulas. (See Chapter V.) 

This section i9 included as a guide to anyone who wishes to add 
information to the OESI system lor its successor). It consists of a list of 
all the kinds of information that are missing. (Filling in these holes should 
be a matter of following the principles of Sect. III.E and imitating the 
formulas that already exist.) 

> Rephrasing can be extended. More principles are needed for comparing 
frequency pictures; some knowledge of Fourier transforms (as opposed to 
frequency pictures) is necessary in order to generate precise side tasks. 

> The time-domain information is non-existent in Appendix 3. The time- 
domain rephrasing problem comes down to trying to find a functional 
relationship between two axiomat ical ly described objects. This is not easy. 

> Many more circuits are needed. Most of the amplifier types mentioned in 
<*CH00SE-AMP> and i 13 satellites are undefined; power amplifiers are a glaring 
omission. The superordinate category of "filter" is entirely absent. There 
9hould be a theory of LC filters and when to use one of them. This should 
uork with a theory of matching impedances during coupling of power stages. 
Time-domain rephrasing will be useless unless it is used to index clippers, 
rectifiers, and other "operational" circuits. 

> Coupling circuits are many and varied. Only one specialized circuit is 
shown in Appendix 3. (See Fig. IV.8.) One difficulty I didn’t mention in 
discussing coupling is choosing polarities of bipolar transistors. These are 
normally NPN, but coupling them directly often constrains them to be of 
opposite polarities. 

> Some of the information shown hanging off circuit diagrams in Chapter I, 
especially interface constraints, has not been represented in the circuit 
schemata of Appendix 3. For example, the system function of the RC filter 
will not be what it claims to be if something is connected to it. 
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1/ Results 


The major result of this research to date is the existence of NASL, DESI, 
and ZORCH. The experience I have had in defining the NASL notation and 
applying it to electronic circuit design is enough by itself to suggest 
certain conclusions. These are the substance of Chapter VI. 

Of course, the claims I make there ui I I be not be decisively proven until 
the program has been debugged and the ZORCH knowledge base has been completed. 
These activities are proceeding, and preliminary results are reported in Sect. 
V.B below. 

Since DESI is intended to be a working system, and since people may wish 
to experiment with it or with the NASL interpreter, these are described from a 
practical point of view in Sect. V.A. I would appreciate comments from those 
who try it out. 

V.A Using DESI 

V.A.l Loading and Running the Program 


To run my programs on the NIT AI Lab 
:I dvm; 
at DDT, then 

(load nasi) 

at LISP. This will load the interpreter 
print loop. (The reader and printer are 
that shouldn’t matter.) Now you can load 


time-sharing system, type 


and leave you in the LISP read-eval- 
not the standard LISP mechanisms, but 
NASL assertions from any file you 


choose (using DEFflLA; see Appendices 2 and 3). To load the designer in, type 
(load desi) instead of or in addition to the above; to load the electronics 
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knowledge, type (load zorch). (Or load the binary file TS OESI, to save a lot 
of time.) 

To run NASL, type 

( 9 tart |action|) 

at LISP, where action is a formula or list structure of the form I/:TASK ...] 
or [|action function|... ]. (In the latter case, if the action has outputs, 
type (start [action| |output9|).) NASL will begin execution, adding the new 
action to i 1 3 task network. When the network is empty, it will return the 
output variables of action if any. It uill also remain in the data pool of 
the action performed, typically a DESIGN, so that you can run new tasks in the 
same environment. , 

V.A.2 DESI Talks to You 

Uhen NASL runs into trouble, or needs the answer to a symbol -manipu I at i on 
problem, it stops and asis you questions to try to help itself out. "Trouble 
is defined as the failure of the choice or rephrasing protocol to achieve its 

1 

aims. In either case, the system stops and tells you its trouble, then asks 
various questions. For example, if it cannot make up its mind after applying 
all the known choice rules, it will ask if it should choose at random. Yes/no 
questions are answered by typing "yes," "y," "no," or "n." Other questions 
will be requests for formulas. (If you type an S-expression where a formula 
is wanted, NASL will convert it.) 

Three standard questions and the reactions to their answers are: 

> "Do you want to 9 ee the reasoning involved?" Answering affirmatively 
causes NASL to re-run the most recent relevant deduction, with the switches 
STP-TRACE-DEPTH* and RECORD-SEE-DEPTH* set to values that let you see the 
steps. (See below,) 
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> "Break?" If you ansuer "yes,” the system will give you a LISP break 
loop. This is usually used for adding new information to the system with 
further DEFfILAs. (DEFMLA may be used to redefine old formulas, too.) Uhen 
you return from the break, the next question in NASL’s list will be asked. 

> "Try again?" Don’t say "yes" unless you’ve taken advantage of the break 
loop and added a new choice principle, a missing axiom that uas needed by the 
last deduction, or some other rule. 


V.A.3 You Talk to DESI 


There are several useful programs for getting debugging information or 

explanations of behavior from OESI. 

(TASK-NET-DUriP) causes the entire active or pending task network under 
your original request to be printed Out in a somewhat readable fashion, with 
indentation, successor pointers, etc. (This function takes an optional task- 
name argument; if it is omitted, your original request is used as a default.) 

(IJHY | task |) causes the task network above the named task to be dumped. 
Notice that asking this question about a frozen task will show you part of the 

teleological structure of the device it appears in, 

(SUPPORT | fact |) prints the supporters of the fact. 

Arm it Dc R ^ SE ,i[ deV ' C ? ^ Prints out the supertasks associated with MAKE-ing or 
ALUUIHL-ing the device (depending on what kind of records of the history of 
the device have been kept). 

I am being a little vague about the precise formats of these functions, 
both because the system encourages you to be vague (it will try to figure out 
whether you are referring to formulas by name or pattern); and because the 
features these functions support are changing rapidly. 

Some useful statistics-gathering functions are defined in the file SNAP. 
The statistics gathered include running times overall, time spent doing 
matching and indexing (important low-level functions of a rule-based system), 
and success of the indexer in keeping garbage from reaching the matcher. 

Typing "(SNAP)" at LISP causes these statistics to be printed out. "(SNAP 
RESET)" resets them; this must be done once to turn them on. (Collecting 
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these statistics slows things down somewhat.) 

There are several switches uhose settings affect the verbiage produced by 
the NASL system. These switches are printed by the function SHOU-SUITCHES, 
defined in SNAP. The switch NASL-TRACE-DETAIL*, an integer from 0 to about 5. 
defines how much the interpreter will tell you about its every move. The 
switch STP-TRACE-DEPTH* controls printing of major sub-goal information by 
STP; if zero, nothing is printed. Similarly, RECORD-SEE-DEPTH* controls 
printing of data-base alterations. Both of these switches are normally zero; 
the system sometimes turns them on to display inferences or model effects. 

(As in Sect. V.B, below.) 


V.B Experimental Results 


The DESI system is still being debugged. Consequently, it has never 

designed a circuit all the uay through. It has done simple choice analysis, 

• • » * * 

trivial equation solution, and’ some rephrasing of simple conjunctive design 


problems. 

Most of the time, the system runs well. Forward deduction and task 
reduction occur in a reasonable amount of time; watching the trace on the 
screen is a pleasant experience. The NASL language is easy to program in; it 
encourages an incremental style of programming in which partial plans 
interact. If an unforeseen interaction occurs, the presence of all task 
information in the data base usually makes the trouble easy to find; fixing it 
is usually a matter of adding a new rule. When it isn’t, the problem usually 
turns out to be a syntactic error in a rule; I strongly recommend to future 
designers of predicate-calculus systems with large rule bases that they 
include checks of syntax (such as proper number and type of arguments to 



V Results 


154 


predicates) at the time a rule is read. In such a system, a wrong rule is 
often overlooked entirely. 

Cal 19 to the theorem prover tend to slow things down. This not because of 
any combinatorial explosion, but probably because of the theorem prover’s 
carefulness in checking subsumption and other special cases which are normally 
irrelevant. The theorem prover is probably too complex for its own good: the 
next such program I write will be much more like Conniver. (McDermott and 
Sussman, 1973) 

Furthermore, the evaluation mechanism (Appendix 4). which i9 normally 
quite efficient, wastes much time in other circumstances. The evaluator is 
called whenever the right-hand side of an implication is detached during 
deduction. It tries to apply reduction rules to every new subexpression of 
the detached formula. This isn’t nearly as expensive as it sounds, because 
one quick index call is enough to check the (very common) case where there are 
no applicable rules. Unfortunately, in detaching the right-hand side of a 
large implication I ike <*+DE'Si-2> in Appendix 2, there is an emharassing 
pause. I am putting up with this for the time being, but it is clear that 
this is a job for some further pragmatic-predicate mechanism. 

As it stands, the system with ZORCH loaded occupies a huge amount of core. 
As incomplete as it is, it takes up about 220K of 36-bit word storage. About 
58K of this is the LISP system and my low-level utilities, and 130K is list 
space, 70% (about 90K) of which i3 occupied. Of th'o, about 30K consists of 
circuit diagrams for the five device types defined in ZORCH! I am sure this 
can be brought down by judicious rearrangement of consequent vs. antecedent 
deduction; the problem appears to be overenthusi ast i c forward reasoning while 
setting up device schemata. However, a lot of storage is required to set up 
and index packets, whether they are used later or not. To duck this probe I m, 
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in the sample runs given below, large conjunctions of the form t/:PKT ...1 
were actually implemented as ordinary formulas like [ANO ...1. In the long 
run, we are going to have to confront the question of organizing secondary 
storage for use by AI programs. 

There are three experimental results to demonstrate. First (Sect. V.0.1), 
I present DESI’s attempt to design a simple amplifier. Then I show its 
pitiful approach to the fiI ter-design problem I described in Chapter I. In 
both these cases, the program crashed due to bugs before going as far as it 
is, in theory, capable. Finally, in Sect. V.B.3, I discuss some research with 
Jon Doyle into the relation between NASL and NOAH. (Sacerdoti, 1975) 


V.B.1 A Simple Amp Iifier 


Here is a sample output from a run of DESI on the first problem in Chapter 

I, with NASL-TRACE-DETAIL# set to 3. fly comments start with The output 

has been edited to relieve the tedium. The dots indicate omissions. In 

this and the next section, apparently random "!’s" in the output are caused by 

garbage collection, one exclamation point per collection. Long strings of 

these marks are indicative of long pauses between outputs. 

;The system was started with by typing 
; (start ’(design ...I ’[<’(winner)>]: 

(CREATING TASK 

(sTASK (*DES*) <> (LAMBDA NIL 

(DESIGN (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(« (V-GAIN ?X) 5) 

(- (INPUT-Z ?X) 30000))))) 

<’(WINNER)>]) 

(ENABLED U*DES*)]) 

(EXECUTING t(*DES*M ...) 

(TASK ((*DES*)) BEING REDUCED) 

(TASK ((*DES*)3 TO BE REPHRASED) 

(CREATING TASK (: TASK (REPHRASER (*DES*)) 

<> 
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(LAMBDA NIL 

(:REPHRASE (*DES*) (DESIGN (LAMBDA (X) 

(AND ...))] 

<’(UINNER)>)) 

<>]) 


(ENABLED (REPHRASER (*DES*)H 
(EXECUTING ! (REPHRASER (*DES*)J 

(!REPHRASE (*DES*) (DESIGN (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(- (V-GA1N ...) 5) 

(- (INPUT-Z ...) 30000)))! 

<’(WINNER)>] 

(<>]) 

(TASK [REPHRASER (*DES*)1 BEING REDUCED) 

(TASK (REPHRASER (*DES*)) REDUCED TO 
(: DO-SUBNET (DESI-REPHRASE-PLAN 

((LAMBDA (X) (AND ...))] (*DES*) <’ WINNER)>) 


;Here are the tasks from the DESIGN rephrase plan <*+DESI-2> 
(CREATING TASK (sTASK (EXPLODER PLAN0380) 

<> 


(LAMBDA NIL 

(D-EXPLODE ((LAMBDA (X) 

(AND ...))])) 

<>]) 

(CREATING TASK (:TASK (ACCOUNT-FOR-ALL PLAN#380) 


<> 

(LAMBDA NIL 

(ACCOUNT-FOR-ALL-SHARDS ((LAMBDA (X) 

(AND ...))])) 

<>]) 

(CREATING TASK (sTASK (CORE-FINDER PLAN0380) 

<> 

(LAMBDA NIL 

(s FI NO (LAMBDA (+DT) 

(CORE-DEV-TYPE (...] ?+DT)))) 

<’(CORE-DT PLAN#380)>]) ! 

(CREATING TASK (:TASK (MAIN-TASK-INFERER PLAN#380) 

<’(CORE-DT PLAN#380)> 

(LAMBDA (+DT) 

(:INFER ’(AND (STASK (MAKER ...) (*DES*) 


(CREATING TASK 


<> 

(LAMBDA NIL 

...) 

<...>) 

(:MAIN (MAKER ...) (*DES*))) 
<(CORE-FINDER PLAN#380)>)> 

<>]) 

(i TASK (SIDE-TASKS-FINDER PLAN#380) 


<> 

(LAMBDA NIL 
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(CREATING TASK 


(CREATING TASK 


(:INFER ’(FORALL (+ST) 
<>)) 

<>]) 


(-> G (SIDE-TASK 
(EXISTS ...))) 


(sTASK (FEATURES-FINDER PLAN0380) 


<> 

(LAMBDA NIL 

(:INFER ’(FORALL (+FT) (-> G (D-FEATURE 

(EXISTS ...))) 

<>)) 

<>]) 

t:TASK (GATHERER PLAN#380) 


(LAMBDA NIL 

(:INFER ’(:REDUCED (*DES*)) 

< (CORE-FINDER PLAN0380) 
(SIOE-TASKS-FINDER PLAN0380) 
(FEATURES-FINDER PLAN0380)>)) 

<>]) ! 

(BLOCKED (MAIN- TASK -1NFERER PLAN0380]) 

(BLOCKED (CORE-FINDER PLAN0380)) 

(ENABLED (ACCOUNT-FOR-ALL PLAN0380)) 

(BLOCKED (EXPLODER PLAN0380I) 

(BLOCKED [GATHERER PLAN#380)) 

(BLOCKED [FEATURES-FINDER PLAN0380]) 

(BLOCKED (SIDE-TASKS-FINDER PLAN#3801) 






?The only task which is enabled is the policy-setup for shard 
;accounting— 


(EXECUTING [ACCOUNT-FOR-ALL PLAN#380] 

[ACCOUNT-FOR-ALL-SHARDS ((LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(« (V-GAIN ...) 5) 

r . I- (INPUT-Z ...) 30000)))]] 

(TASK [ACCOUNT-FOR-ALL PLAN0380] 

BEING REDUCED) 

(TASK [ACCOUNT-FOR-ALL PLAN0380] 

REDUCED TO (:PRIM *SETUP]) 

5 But the first real task is the exploder 

(ENABLED (EXPLODER PLAN0380)) 

(EXECUTING (EXPLODER PLAN0380] 

[D-EXPLODE ((LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(= (V-GAIN ...) S) 

U (INPUT-Z ...) 30000)))]] 

[<>]) 

(TASK [EXPLODER PLAN0380] BEING REDUCED) 

(TASK [EXPLODER PLAN#380] REDUCED TO 

l: INFER ’(D-SHARD ((LAMBDA (X) (AND ...))] 
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[(LAMBDA (X). (AND ...))]) 

<>]) 

{The system prints out a lengthy list of deductions from this inferred 
{ "d-shard": 

(INFERENCES MADE BY [EXPLODER PLAN#380) 

— ) 

(RECORDING [D-SHARD ((LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(« (V-GAIN ...) 5) 

(= (INPUT-Z ...) 30000)))] 

[(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(= (V-GAIN ...) 5) 

(- (INPUT-Z _) 30000))))] 

0 ) 

;It turns the elements of the conjunction into shards 
(RECORDING (:GEN (NOT (ELT ?+C A 4 <(DEV-TYPE ?X AMPLIFIER] 

[- (V-GAIN ...) 5] 

[= (INPUT-Z ...) 30000]>)) 

(D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 

(« ... 5) 

(» ... 30000)))] 

[(LAMBDA (X) _?+C~4)])] 

0 ) ! 

{The first of three major shards: 

A ’ 

(RECORDING [D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(= (V-GAIN ...) 5) 

U (INPUT-Z ...) 30000)))] 

[(LAMBDA (X) (- (INPUT-Z ?X) 30000)))] 

0 ) 

• • • 

{The tells DESI one side might be a control quantity: 

(RECORDING [POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(- (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))] 

[X] [INPUT-Z ?X) [30000]) 

0 ) 

(RECORDING (:GEN (NOT (AND (NOT (CONTAINS (30000] [?? X))) 

(=> ’(DEN ...) ?F~9) 

(CONTROL-ATTRIBUTE ?F A 9) 

(=> ’(DEN ?+F A 9) ?F A 9))) 

(SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 

(» ... 5) 
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30000)))] 

[(LAMBDA (X) (CONSTRAIN <...> (LAMBDA ...)))])] 

0 ) 

(RECORDING (POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(- (V-GAIN ...) 5) 

(» (INPUT-Z ...) 30000)))] 

[X] [30000] (INPUT-Z ?X]] 

0 ) 

(RECORDING [sGEN (NOT (AND (NOT (CONTAINS IINPUT-Z ...] 

[?? X])) 

(-> ’(DEN ...) ?F A 9) 

(CONTROL-ATTRIBUTE ?F A 9) 

(=> ’(DEN ?+F A 9) ?F A 9))) 

(SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ... AMPLIFIER) 

(- ... 5) 

(- ... 30000)))] 

[(LAMBDA (X) (CONSTRAIN <...> (LAMBDA ...)))])] 

0 ) ! 


;Having noticed that INPUT-Z is a control attribute, it uses the rule 
; INPUT-Z-SHARD to classify the desired impedance: 


(RECORDING t:GEN (NOT (- 30000 ?Z A 7)) 

(AND (:GEN (NOT (> ?Z A 7 300000.0)) 

(D-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z VERY-HIGH])) 
(:GEN (NOT (AND (> ?Z A 7 1500.0) 

(< ?Z A 7 500000.0))) 

(D-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z HIGH])) 

(sGEN (NOT (AND (> ?Z A 7 500) 


0 ) 


(< ?Z A 7 2000.0))) 

(D-FEATURE [(LAMBDA ...)] 

[RANGER INPUT-Z MODERATE])) 
(:GEN (NOT (< ?Z A 7 1000)) 

(D-FEATURE [(LAMBDA ...)) 

[RANGER INPUT-Z LOU])))] 


(RECORDING [AND (:GEN (NOT (> 30000 300000.0)) 

(D-FEATURE [(LAMBDA (X) (AND ...))] 

[RANGER INPUT-Z VERY-HIGH])) 

(:GEN (NOT (AND (> 30000 1500.0) (< 30000 500000.0))) 
(D-FEATURE [(LAMBDA (X) (AND ...))] 

[RANGER INPUT-Z HIGH])) 

(:GEN (NOT (AND (> 30000 500) (< 30000 2000.0))) 
(D-FEATURE ((LAMBDA (X) (AND ...))] 

[RANGER INPUT-Z MODERATED) 

(:GEN (NOT (< 30000 1000)) 

(D-FEATURE [(LAMBDA (X) (AND ...))] 

[RANGER INPUT-Z LOU)))] 


0 ) 
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l The winning feature is "high input impedance": 

(RECORDING ID-FEATURE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 

(« (INPUT-Z ...) 30000)))) 
[RANGER INPUT-Z HIGH]) 

0 ) 


;A similar deduction is done for the case of voltage gain: 


(RECORDING [D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))) 
[(LAMBDA (X) (- (V-GAIN ?X) 5)))) 


0 ) 


(RECORDING [POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
{« (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))) 
(X) [V-GAIN ?XJ [5)1 

0 ) 


(RECORDING [POS-CQ-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))) 
IX) (5) (V-GAIN ?X)J 

0 ) 


(RECORDING (SIDE-TASK [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(« (V-GAIN ...) 5) 

<- (INPUT-Z ...) 30000)))) 

[(LAMBDA (X) 

(CONSTRAIN <’...> (LAMBDA (Gl) (= ... 5)))))) 

0 ) 


(RECORDING [AND (:GEN (NOT (> S 1000)) (D-FEATURE [(LAMBDA (X) 

(AND ...))) 

[RANGER V-GAIN VERY-HIGH])) 
(:GEN (NOT (AND (> 5 50) (< 5 5000))) 

(D-FEATURE ((LAMBDA (X) (AND ...))) 

[RANGER V-GAIN HIGH))) 

(:GEN (NOT (AND (> 5 1) (< 5 100))) 

(D-FEATURE ((LAMBDA (X) (AND ...))) 

[RANGER V-GAIN MODERATE))) 

(:GEN (NOT (-< 5 D) (D-FEATURE ((LAMBDA (X) (AND ...))) 
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0 ) 


[RANGER V-GAIN LOU]))] 


(RECORDING [D-FEATURE 


0 ) 


[RANGER 


[ (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(- (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))] 
V-GAIN MODERATEJI 


;The last d-ahard gives us the core device type: 

(RECORDING (D-SHARD [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

(= (V-GAIN ...) 5) 

(« (INPUT-Z ...) 30000)))] 
((LAMBDA (X) (DEV-TYPE ?X AMPLIFIER))]] 

0 ) ! 

(RECORDING (CORE-DEV-TYPE [(LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 
(= (V-GAIN ...) 5) 

(- (INPUT-Z ...) 30000)))] 

[AMPLIFIER]] 

0 ) 

(♦INFERENCES DONE*) 


{This concludes the inferences of the exploder 

{Now the other tasks of the rephrasing plan assemble the features, core 
{device type, and constraints into a new task network: 

(ENABLED (FEATURES-FINDER PLAN0380]) 

(ENABLED (CORE-FINDER PLAN#380]) 

(EXECUTING (CORE-FINDER PLAN0380] 

({FIND (LAMBDA (+DT) 

(CORE-DEV-TYPE [(LAMBDA (X) 

(AND ..))] 

?+DT))] 

(<’(CORE-DT PLAN0380)>]) 

(TASK (CORE-FINDER PLAN//380] PRIMITIVE) ! 

(OLD TASK [MAIN-TASK-INFERER PLAN0380] 

HAS ACTION [:INFER ’(AND (STASK (MAKER (*DES*)) 

(*DES*) 

<> 

(LAMBDA NIL (MAKE (DEN ...))) 

<’(UINNER ...)>) 

(-•MAIN (MAKER (*DES*)) 

(jiXIPQ*) ) 1 

<(CORE-FINDER PLAN#380)>]) 

(ENABLED [MAIN-TASK-1 NFERER PLAN//380]) 

(FINISHED [CORE-FINDER PLAN0380]) 


{Retrieval of the core device type enables the system to infer 
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;the main task: 

(EXECUTING tflAIN-TASK-1NFERER PLAN#380) 

(:INFER ’(AND (STASK (MAKER (*DES*)) (*DES») 

<> 

(LAMBDA NIL (MAKE (DEN ...))) 

<’(WINNER ...)>) 

(:MAIN (MAKER (*DES*)) (*DES*))) 

<(CORE-FINDER PLAN#380)>) 

(<>]) 

(TASK (MAIN-TASK-INFERER PLAN#380) 

PRIMITIVE) 

(INFERENCES MADE BY [MAIN-TASK-1 NFERER PLAN#380) 

— ) 

(RECORDING l:TASK (MAKER (*DES*)) <> (LAMBDA NIL (MAKE AMPLIFIER)) 
<’(WINNER (*DES*))>) 

0 ) 

(CREATING TASK Is TASK (MAKER (*DES*)) <> 

(LAMBDA NIL (MAKE AMPLIFIER)) 

<’ (WINNER (.*0ES*))>)) 

(RECORDING (:SUBTASK (MAKER (*DES*)) (*DES*)) 

0 ) 

(RECORDING [:MAIN (MAKER (*DES*)) (*DES*)) 

0 ) 

(♦INFERENCES DONE*) ! 

{End of inferences by main task inferer 

(ENABLED ISIDE-TASKS-FINDER PLAW/380)) 

(FINISHED [MAIN-TASK-INFERER PLAN#380)) 

(BLOCKED [MAKER (*OES*)]) 


;Now the features of the desired device cause policies to be created: 
(EXECUTING [FEATURES-FINDER PLAN#380) 

[: INFER '(FORALL (+FT) (-> G (D-FEATURE (...) ?+FT) 

(EXISTS (T) (AND (STASK ...) 

(:SCOPE ...) 

(:SUCCESSOR ...))))) 

<>] 

[<>)) 

(TASK [FEATURES-FINDER PLAN#380) 

PRIMITIVE) 

(INFERENCES MADE BY [FEATURES-FINDER PLAN#380I 
—) 

(RECORDING [:GEN (NOT (D-FEATURE [(LAMBDA (X) (AND ...))) 

?+FT)) 

(AND (STASK TI400/11G5 (*DES*) 

<> 

(LAMBDA NIL (D-NOTE (DEN ?+FT))) 

<>) 

(:SCOPE T!400/11S5 (MAKER (*DES*))) 

(:SUCCESSOR T1400/1165 (MAKER (*DES*))))1 


0 ) 
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(RECORDING (:TASK TI400/1691 <> (LAJ1BDA NIL 

(D-NOTE (RANGER INPUT-Z HIGH))) 

<>) 

0 ) 

(CREATING TASK t:TASK TI400/1691 <> (LAMBDA NIL 

(D-NOTE (RANGER INPUT-Z HIGH))) 

<>]) 

(RECORDING [:SUBTASK T1400/1691 (*DES*)) 

0 ) 


{Noting the SCOPE of the task triggers several rules for 
{suggesting ways to make an amplifier: 

(RECORDING (.-SCOPE T!400/1691 (MAKER (*DES*))) 

0 ) 

(RECORDING (: ANTEC (NOT (: POL ICY TI400/1G91 

(O-NOTE (RANGER V-GAIN MODERATE)))) 

(:TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV A 29> 
(MAKE CE))I 

0 ) 

(RECORDING (s ANTEC (NOT (: POL ICY T1400/1691 

(D-NOTE (RANGER V-GAIN HIGH)))) 

(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV A 29> 
(MAKE N-STAGE))] 

0 ) 

(RECORDING (:ANTEC (NOT (:POLICY T1400/1691 

(D-NOTE (RANGER V-GAIN VERY-HIGH)))) 
(sTO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?0EV A 29> 
(MAKE OP-AMP))] 

0 ) 

(RECORDING (:ANTEC (NOT ({POLICY T1400/1691 

(D-NOTE (RANGER FREQ-OP VERY-LOU)))) 
(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV A 29> 
(MAKE DIFF-AMP))) 

0 ) ! 

(RECORDING t:ANTEC (NOT (-.POLICY T1400/1691 

(D-NOTE (RANGER INPUT-Z HIGH)))) 

(:TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?0EV A 29> 
(MAKE CC))) 

0 ) 

(RECORDING [{ANTEC (NOT ({POLICY T1400/1691 

(D-NOTE (RANGER P-GAIN HIGH)))) 

(AND (:TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) 
<?0EV A 29> 

(MAKE COMP-SYM)) 

(:TO-DO (MAKER (*OES*)) (MAKE AMPLIFIER) 
<?DEV A 29> 

(MAKE PUSH-PULL) M) 

0 ) 

(RECORDING I: ANTEC (NOT ({POLICY ?PTASK A 29 (MAKER (*OES»)) 

(D-NOTE LINEAR))) 

(: TO-DO (MAKER (*0ES»)) (MAKE AMPLIFIER) <?DEV A 29> 


n 
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(MAKE CE))3 


0 ) 

(RECORDING [{SUCCESSOR TI400/1691 (MAKER (*OES*))l 
0 ) 


(RECORDING [{TASK T!400/2154 <> (LAMBDA NIL 

(D-NOTE (RANGER 


V-GAIN MODERATE))) 


<>] 


0 ) 

(CREATING TASK [{TASK T!400/2154 <> 

(LAMBDA NIL (D-NOTE (RANGER 
<>)) 

(RECORDING [{SUBTASK TI400/2154 (*DES*)1 
0 ) 

(RECORDING [{SCOPE T1400/2154 (MAKER (*OES*))] 
0 ) 


V-GAIN MODERATE))) 


{Similarly for this feature: 

(RECORDING [:ANTEC (NOT ({POLICY T1400/2154 

(D-NOTE (RANGER V-GAIN MODERATE)))) 
({TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) <?DEV-29> 
(MAKE CE))1 

0 ) 

{The same rules will be found again (a slight non-optimality 
{ in the phrasing of the these rules) 


(RECORDING [{SUCCESSOR T!400/2154 (MAKER (*QES*))1 
0 ) 

(♦INFERENCES DONE*) ! 

{End of inferences by features finder. 

(FINI SHED [FEATURES-FINDER PLAN#3801) 

(BLOCKED [T1400/1691)) 

(BLOCKED [T1400/21541) 

{The side-tasks finder similarly turns side-task shards into CONSTRAIN 
• ^dsK s • 

(EXECUnNG [SIDE-TASKS-FINDER PLAN#3801 

[{INFER ’ (FORALL (+ST) (-> G (SIDE-TASK [...1 ?+ST) 

(EXISTS (T) (AND (STASK ...) 

({SUCCESSOR ...))))) 

<>] 

[<>]) 

(TASK [SIDE-TASKS-FINDER PLAN0380] 

PRIMITIVE) 

(INFERENCES MADE BY [SIDE-TASKS-FINDER PLAN#3801 
—) 

(RECORDING [{GEN (NOT (SIDE-TASK [(LAMBDA (X) 

(AND —)) 1 

?+ST)) 

(AND (STASK T1401/6707 (*OES*) 
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0 ) 


<’(WINNER (*DES*))> 
(DEN ?+ST) 

<>) 

(:SUCCESSOR (MAKER (*DES*H 
T!401/6707)) ] 


• • • 

(RECORDING (sTASK TI401/340G <’(WINNER (*DES*))> 
(LAMBDA (X) 

(CONSTRAIN <*(V-GAIN ?X)> 

(LAMBDA (Gl) (= ?G1 5)))) 

<>] 

0 ) 

(CREATING TASK (:TASK T!401/3406 <’(WINNER (*DES#))> 
(LAMBDA (X) 

(CONSTRAIN <’(V-GAIN ?X)> 
(LAMBDA (Gl) (» ?G1 5)))) 

<>]) 

(RECORDING (:SUBTASK T1401/3406 (*DES*)) 

0 ) 

(RECORDING l:SUCCESSOR (MAKER (*DES*)) 

T1401/3406) 

0 ) 

(♦INFERENCES DONE^) 

;End of inferences by side-tasks finder. 


(ENABLED (GATHERER PLAN0380)) 

(FINISHED (SIDE-TASKS-FINDER PLAN0380)) ! 
(BLOCKED (T!401/3406)) 


; The "gatherer" just marks the design task reduced: 
(EXECUTING [GATHERER PLAN#380] 

CsINFER ’(:REDUCED (♦DES*)) <(CORE-FINDER PLAN#380) 

(SIOE-TASKS-FI NDER PLAN//380) 
(FEATURES-FINDER PLAN#380)>) 

(<>)) 


(TASK [GATHERER PLAN#380J PRIMITIVE) 

(INFERENCES MADE BY [GATHERER PLAN0380) 

— ) 

(RECORDING (:REDUCED (*DES*)) 0) 

(♦INFERENCES DONE^) 

5 The interpreter will see this message in a second. 


(ENABLED [(♦DES^H) ! 
(FINISHED [GATHERER PLAN#3801) 


;Nou the task is reattempted: 

(EXECUTING [ (>*cDES*)) [DESIGN (LAMBDA (X) 

(AND (DEV-TYPE ?X AMPLIFIER) 

( = (V-GAIN ?X) 5) 

(- (INPUT-Z ?X) 30000)))] 

[<’(WINNER)>)) 

(TASK [(♦DES^H ALREADY REDUCED) -.The /:REDUCED formula is seen 
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(ENABLED [T!400/1691J) 
(ENABLED (T!400/2154]) 


;The policies are put into effect: 

(EXECUTING CT *400/2154] (D-NOTE (RANGER V-GAIN MODERATE)] 
[<>]) 

(TASK (T1400/2154] BEING REDUCED) 

(TASK (T!400/2154] REDUCED TO l:PRIM *SETUP]) ! 
(EXECUTING [TI400/1691] (O-NOTE (RANGER INPUT-Z HIGH)] 
(<>]) 

(TASK (T1400/1691] BEING REDUCED) 

(TASK (T1400/1691) REOUCED TO (:PRIM *SETUP]) 


{Recording these policies causes two of the rules inferred above to 
{ f i re... 


(ENABLED (MAKER (*DES*)J) 

(EXECUTING (MAKER (*DES*)] (MAKE AMPLIFIER] 
(<’(WINNER (*DES*))>]) 

(TASK [MAKER (*DES*)J BEING REDUCED) 


{...so there are two ways, common emitter and common collector, 
{to make an amplifier 
(MAKING A CHOICE) 

(RECORDING I {CHOICE CHOICE0402 EXEC ( 

I; TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’WINNER (*0ES*))> 

?UAY] ] 

0 ) 

{The system records first the choice, then the options. 
{Recording the choice causes a flock of choice rules to.be 
{instantiated: 

(RECORDING (:GEN (NOT (:» (MAKER (*DES*)) ?AMP-TASK~3)) 

(AND (CHOOSE-AMP-PKT CHOICE#402 ?AMP-TASK A 3 

[MAKER (*DES*H [’(WINNER ...)] C7UAY3) 

(:GEN (NOT (:SCOPE ?PTSK A 3 ?AMP-TASK^3)) 
TRUE))] 

0 ) 


{The choice rules come in a packet: 

(RECORDING [CHOOSE-AMP-PKT CHOICE#402 (MAKER (*DES*)) 

[MAKER (*DES*)] 

[’(WINNER (*DES*))] 

[?UAY]] 

0 ) 

{This odd-looking formula is intended to trigger antecedent 
{ rules in the packet which would otherwise not be noticed 
(RECORDING (:GEN (NOT (:SCOPE ?PTSK A 4 (MAKER (*DES*)))) 

TRUE] 

0 ) ! 

{ ... such as this one: 

(RECORDING [: ANTEC (NOT (:SCOPE 7PTSK1 (MAKER (*DES*)))) 

(:GEN (NOT (AND ({POLICY 7PTSK1 (D-NOTE LINEAR)) 
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0 ) 


(:SCOPE 7PTSK2 (MAKER (*DES*))) 

(:POL ICY 7PTSK2 

(O-NOTE (RANGER P-GAIN HIGH))) 
(■=> ’(DEN ...) 7PTSK2))) 

(:ANTEC (NOT (:OPT ION CHOICE0402 ?A1 [:TO-DO ...])) 
. (:GEN (NOT (OPT-SUPPORT ?A1 ...)) 

(:RULE-TOGETHER <?A1> t:TO-DO ...]))))] 


(RECORDING Is SCOPE TI400/2154 (MAKER (*DES*))I 
0 ) 

(RECORDING t:SCOPE T1400/1691 (MAKER (*DES*))I 
0 ) 


;Here is the first option 

(RECORDING hOPTION CHOICE#402 OPT#403 t: TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) 

<’WINNER (*DES*))> 

(MAKE COD 

0 ) 

;It finds a rule 

(RECORDING (:ANTEC (NOT (:OPTION CHOICE0402 ?A1 

f:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <_?+N> 

(MAKE _?+DTl)I)) 

(sGEN (NOT (OPT-SUPPORT ?A1 

t:POL ICY J7+PTASK (D-NOTE ...)])) 

(:ANTEC (NOT (sOPTION CHOICE0402 7A2 t:TO-DO ...I)) 

(:GEN (« ?A1 7A2) (sRULE-TOGETHER <?A1 ?A2> 

I:TO-DO ...]))))] 

0) 

;and checks the support for the options to see if input impedance 
: was relevant 

(RECORDING f:GEN (NOT (OPT-SUPPORT OPT#403 

(:POL ICY _?+PTASK A 3 

(D-NOTE (RANGER INPUT-Z _...))])) 

(:ANTEC (NOT (:OPTION CHOICE0402 ?A2 A 3 

t:TO-DO (MAKER ...) (MAKE AMPLIFIER) 

(MAKE _...)])) 

(:GEN (- OPT#403 ?A2 A 3) 

(:RULE-TOGETHER <OPT#403 ?A2 A 3> 

[:TO-DO (MAKER ...) (MAKE AMPLIFIER) <...> 
(MAKE ...)])))•] 

0 ) ! 

;It uas 

(RECORDING tsANTEC (NOT (:OPTION CHOICE#402 ?A2 A 4 

(:TO-DO (MAKER (*0ES*)) 

(MAKE AMPLIFIER) <’...> 

(MAKE _?+DT2 A 4)])) 

(:GEN (= OPT#403 ?A2 A 4) 

(jRULE-TOGETHER <OPT#403 ?A2 A 4> 
t:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’...> 


n 



V Results 


168 


0 ) 

(RECORDING [:GEN (- 


0 ) 


(MAKE (CASCADE CC _...))]))] 

OPT#403 OPT#403) (:RULE-TOGETHER <OPT#403 OPT#403> 

(:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) 

<’(WINNER ...)> 

(MAKE (CASCADE CC CC))])] 


5 The rule excludes cascading something with itself, so this line of 
5 inference dies. 


;Here is the second option: 

(RECORDING (sOPTION CHOICE#402 OPT0404 
t:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’(WINNER (*DES#))> 
(MAKE CE)]] 

0) 


jit is checked for input impedance being relevant 
(RECORDING (:GEN (NOT (OPT-SUPPORT OPT#404 (sPOLICV _?+PTASK^3 

(D-NOTE (RANGER INPUT-Z 

...))])) 

(:ANTEC (NOT (: OPT I ON CHOICE0402 ?A2 / '3 

t:TO-DO (MAKER ...) (MAKE AMPLIFIER) 


0) ! 

511 isn’t. 
{triggers. 


<... > 

(MAKE _...)])) 

(:GEN (- OPT#404 ?A2 A 3) (:RULE-TOGETHER <OPT#404 

?A2 A 3> 

1: TO-DO (MAKER ...) 
(MAKE AMPLIFIER) 

‘ <... > 

(MAKE_ )])))] 

However, the /:ANTEC derived from the other option 


(RECORDING (sGEN (= OPT0403 OPT0404) 

(: RULE-TOGETHER <OPT#403 OPT#404> 

I:T0-00 (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’(WINNER ...)> 
(MAKE (CASCADE CC CE))])] 

0 ) 

; and the appropriate cascade is suggested: 

(RECORDING (:RULE-TOGETHER <OPT04.03 OPT#404> 

(: TO-DO (MAKER (*0ES*)) (MAKE AMPLIFIER) 

<’(WINNER (*DES*))> 

(MAKE (CASCADE CC CE))]] 

0 ) ! 

(RECORDING [sOPTION CHOICE0402 NEUOPT0405 
(:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’(WINNER (*0ES*))> 
(MAKE (CASCADE CC CE))]] 


0 ) 
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;This new option goes through the mill also 
(RECORDING [:GEN (NOT (OPT-SUPPORT NEWOPT#405 

C:POLICY _?+PTASK*3 

(D-NOTE (RANGER INPUT-Z _...))])} 

(:ANTEC (NOT (:OPT I ON CHOICE0402 ?A2^3 

(:T0-00 (MAKER ...) (MAKE AMPLIFIER) 

(MAKE _...)])) 

(:GEN (- NEWOPT0405 ?A2 A 3) 

(:RULE-TOGETHER <NEWOPT#405 ?A2~3> 
t:TO-DO (MAKER ...) (MAKE AMPLIFIER) 

^ ^ 

(MAKE ...)])))] 

0 ) 


;A rather unpromising cascade is suggested: 

(RECORDING (:GEN (- OPT0403 NEWOPT#405) 

(: RULE-TOGETHER <OPT#403 NEWOPT#405> 

(:TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) 
<’(WINNER ...)> 

(MAKE (CASCADE CC (CASCADE CC CE)))])] 

0 ) 

(RECORDING (:RULE-TOGETHER <OPT#403 NEWOPT#405> 

(: TO-DO (MAKER (*DES*)) (MAKE AMPLIFIER) 

<’(WINNER (*DES*))> 

(MAKE (CASCADE CC (CASCADE CC CE)))]3 

0 ) 


»but for some reason vanishes. (Notice that the rule should be, 

! "If x was suggested because of its input impedance and y wasn’t. 

; cascade them." Then this cascade would never have been suggested.) 


»The /:RULE-TOGETHER causes the old options to be flushed 
(FLUSHED {:CONSEQ (:0PTI0N CHOICE//402 OPT0404 (:T0-D0 (MAKER (*DES*)) 


(FLUSHED 


FALSE]) 


(MAKE AMPLIFIER) 
<’(WINNER ...)> 
(MAKE CE)J) 


(:CONSEQ (:RULE-TOGETHER <OPT#403 OPT#404> 
(:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) 

<’(WINNER ...)> 

(MAKE (CASCADE CC CE))]) 

FALSE]) 


(FLUSHED (:CONSEQ (tOPTION CHOICE#402 OPT#403 

(:TO-DO (MAKER (*DES*)) 


(MAKE AMPLIFIER) <’(WINNER ...)> 
(MAKE CCH) 

FALSE]) 

(FLUSHED (: ANTEC (NOT (: OPT I ON CHOICE0402 ?A2 A 4 

(:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’...> 

(MAKE _?+DT2*4)])) 

(:GEN (- OPT#403 ?A2 A 4) 


it 
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(: RULE-TOGETHER <OPT#403 ?A2 A 4> 
t:T0-00 (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’...> 

(MAKE (CASCADE CC _...)))))]) 

(FLUSHED [:CONSEQ (:RULE-TOGETHER <OPT#403 NEWOPT#405> 

l:TO-DO (MAKER (*DES*)) 

(MAKE AMPLIFIER) <’(WINNER ...)> 

(MAKE (CASCADE CC (CASCADE CC CE)))1) 

FALSE)) 

(CHOICE CHOICE#402 DONE) 

{The choice successfully reduced the design problem: 

(TASK [MAKER (*DES*)] REDUCED TO [MAKE (CASCADE CC CE) 1) 

(CREATING TASK [:TASK G0248 <> (LAMBDA NIL 

(MAKE (CASCADE CC CE))) 

<’(WINNER (*DES*))>)) 

(NEW TASK [G0248] HAS ACTION [MAKE (CASCADE CC CE) 3) 

(ENABLED [G02483 ) 

(EXECUTING [G0248J (MAKE (CASCADE CC CE)] 

[<’(WINNER (*DES*))>]) 

(TASK [G02481 BEING REDUCED) 

{There is a standard plan for doing cascades: 

(TASK [G02481 REDUCED TO (:DO-SUBNET (CASCADE-PLAN CC CE) 

<CASCADE-NAME>]) ! 

(CREATING TASK [:TASK (MAKER-1 PLAN#40G) 

<> (LAMBDA NIL (MAKE CC)) 

<’(FIRST-DEV PLAN#406)>)) 

(CREATING TASK [:TASK (MAK£R-2 PLAN#406) 

<> (LAMBDA NIL (MAKE CE)) 

<’(SECOND-DEV PLAN#406)>]) 

(CREATING TASK [:TASK (GRABBER PLAN#406) <> 

(LAMBDA NIL 

(GRABBA (LAMBDA (X) 

(MAIN-DEV-TYPE ?X (CASCADE CC CE))))) 

<’(CASCADE-NAME PLAN0406)>1) 

(CREATING TASK (:TASK (COUPLER PLAN#406) 

<’(FIRST-DEV PLAN#406) ’(SECOND-DEV PLAN#406)> 

(LAMBDA (D1 D2) (COUPLE ?D1 ?D2)) 

<>]) ! 

At this point a bug in the specification for the cascade plan caused the 
system to crash. (This would have been caught by a syntax checker of the kind 
I mentioned above.) In any case, the system currently lacks knowledge of 
common-collector circuits and constraint analysis, so it could not have gone 


much further. 
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V.B.2 Converting a Square Have into a Sine Have 


In this section I present the someuhat more disappointing behavior of DESI 
on the job of converting a 1 kHz square wave into sine wave of the same 
frequency, expressed as follows 


(design 
(\ (ckt) 

(convert ?ckt 
(\ (in) 

(and (periodic (tfun ?in) 1.0E-3) 
(foraII (t) 


< 


(and (implies (/< ?t 0) 

(» ((one-period (tfun ?in)) 
D) 

(implies (not (/< ?t 0)) 

(= ((one-period (tfun ?in)) 
- 1 ))) )) ) 

(\ (in out) 

(= (tfun ?out) 

(\ (t) (sin (* 2000 pi ?t)) )) )) 

(fiI ter)>]) 


?t) 

?t) 

) 


) 


;The initial part of the sequence is just as in Sect. V.B.l 
(CREATING TASK 

I:TASK (*DES*) <> 

(LAMBDA NIL 

(DESIGN (LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...))))) 
<’(FILTER)>]) ! 

(ENABLED t(*DES*)]) 

(EXECUTING I (*DES*)]...) 

(TASK I(*DES*)] BEING REDUCED) 

(TASK [(*DES*)I TO BE REPHRASED) 

(CREATING TASK [-.TASK (REPHRASER (*0ES*)) 


<> 

(LAMBDA NIL 

(:REPHRASE (*DES*) (DESIGN (LAMBDA .. 
<’(FILTER)>)) 

<>]) 


(ENABLED (REPHRASER (*DES*))) 

(EXECUTING (REPHRASER (*DES*)] 

(:REPHRASE (*DES*) [DESIGN (LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ... 
(LAMBDA ...)))] 

<’(FILTER)>] 


[<>]) 


(TASK [REPHRASER (*DES*)I BEING REDUCED) 
(TASK [REPHRASER (*DES*)) REDUCED TO 


)] 
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[: DO-SUBNET (DESI-REPHRASE-PLAN 

[(LAMBDA (CKT) (CONVERT_)) J (*DES*) ’(FILTER)) 

<>]) ! 

• • • 

;I have elided the messages regarding setting up the rephrasing 
; network. (They are the same as for the preceding example.) 

• • • 

(EXECUTING [ACCOUNT-FOR-ALL PLAN#392) 

[ACCOUNT-FOR-ALL-SHARDS 

[(LAMBDA (CKT) (CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))]] 

[<>]) 

(TASK [ACCOUNT-FOR-ALL PLAN0392] BEING REDUCED) 

(TASK [ACCOUNT-FOR-ALL PLAN#392I REDUCED TO [:PRIM *SETUP1) 

(ENABLED [EXPLODER PLAN#392)) ! 

(EXECUTING [EXPLODER PLAN#392) 

[O-EXPLOOE [(LAMBDA (CKT) (CONVERT ?CKT (LAMBDA ...) (LAMBDA ...))))) 
[<>]) 

(TASK [EXPLODER PLAN0392I BEING REDUCED) 


{Explosion begins as before... 

(TASK [EXPLODER PLAN#392) REDUCED TO [{INFER ’(O-SHARD [(LAMBDA ...)) 

[(LAMBDA ...))) 

<>]) 

(INFERENCES MADE BY (EXPLODER PLAN0392) 

— ) 

(RECORDING [D-SHARD [(LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...)))] 
[(LAMBDA (CKT) 

(CONVERT ?CKT (LAMBDA ...) (LAMBDA ...))))] 

0 ) 

;But this time the main shard is too hairy to be handled by STP, 

{ so a subtask is set up 

(RECORDING [{TASK T11379/2344 <> 

(LAMBDA NIL (CVT-EXPLODE [(LAMBDA ...)] [(LAMBDA ...)])) 
<>] 

0 ) 

(CREATING TASK [.-TASK T11379/2344 <> 

(LAMBDA NIL (CVT-EXPLODE ((LAMBDA ...)] 

[(LAMBDA ...)])) 

<>)) 

(RECORDING [iSUBTASK T11379/2344 (EXPLODER PLAN0392)] 

0 ) 

(RECORDING [{MAIN T11379/24 (EXPLODER PLAN#392)I 
0 ) 

{The same rule <*CONVERT-EXPLODE> also sets up a rule to infer 
{ SIG-TRANS d-shards from the "signal features" that fall out 
{ of the convert explosion... 

(RECORDING I:ANTEC (NOT (SIG-FEATURE [(LAMBDA ...)] [(LAMBDA ...)J 

?+FEATURE~47)) 

(D-SHARD [(LAMBDA (CKT) (CONVERT ...))] 
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((LAMBDA (CKT) (SIG-TRANS CKT ...))])] 

0) 

(♦INFERENCES DONE*) 


;Uork begins on this sub task 
(ENABLED (T11379/2394)) 

(EXECUTING (T1!379/2335) 

(CVT-EXPLODE ((LAMBDA (IN) (AND (PERIODIC ... 0.001) 

(FORALL ...)))] 

r , ((LAMBDA (IN OUT) (« (TFUN ...) (LAMBDA ...))))) 

(<>]) ! 

(TASK (T11379/2395) BEING REDUCED) 


;But there is a choice whether to look for frequency-domain 
; or time-domain features of the siqnals 
(MAKING A CHOICE) 

(RECORDING (sCHOICE CHOICER 10 EXEC 
I:TO-DO T11379/4711 

(CVT-EXPLODE (...) [...]) <> 

?UAYJ) 

0 ) 

(RECORDING [jANTEC (NOT (.-OPTION CHOICE0410 7AK3 

(:TO-DO T11379/4711 (CVT-EXPLODE ...) 


(FREQ-DOMAIN-REPHRASE ...)))) 
(: ANTEC (NOT (: OPT I ON CHOICE#410 ?A2' V 3 


(:TO-DO ...))) 

(AND (:GEN (NOT (AND ...)) (s RULE-IN ?A1 /S 3)) 
(:GEN (NOT (AND ...)) (:RULE-IN ?A2 A 3)) 
(:.GEN (NOT (AND ...)) 

(:RULE-OUT ?A2 A 3))))) 

0 ) 

(RECORDING ({OPTION CHOICE#410 0PT#411 (sTO-DO T11373/4711 

(CVT-EXPLODE (...) 

(...)) 


0 ) 

(RECORDING ({OPTION CHOICE0410 OPT0412 


<> 

(TIME-OOMAIN-REPHRASE (. 

[...)))) 


tsTO-DO T11379/4711 
(CVT-EXPLOOE (...) 
(...)) 


) 


<> 

(FREQ-DOMAIN-REPHRASE (...) 


(RECORDING (sANTEC (NOT (:OPTION CHOICE0410 ?A2~5 

(sTO-DO T11379/4711 (CVT-EXPLODE ...) 
<> 


(TIME-DOMAIN-REPHRASE ...)])) 
(AND (:GEN (NOT (AND (:= ...) (NOT ...))) 

(:RULE-IN OPT0412)) 

(:GEN (NOT (AND (:- ...) (NOT ...))) 


n 
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(:RULE-IN ?A2~5H 

(:GEN (NOT (AND (:SUBTASK ...) (jTASK-ACTION ...) 
(: = ... ACTIVE) 

(D-FEATURE ...))) 

(sRULE-OUT ?A2 A 5)))3 


;The choice depends upon what the signal-description predicates 
; depend on. (See <*CVT-CHOICE> in Appendix 3.) 

(RECORDING t:GEN (NOT (AND (:- [...] [...]) (NOT (CONTAINS P+BOOV^G 

...)))) 


(:RULE-IN OPT0412)] 

0 ) !!! 


;Frequency-domain is indicated— 
(RECORDING (:RULE-IN OPT0412] 0) 


(RECORDING I:GEN (NOT (AND (:- [...] 
(:RULE-IN 0PT#411)J 


(...]) (NOT (CONTAINS ?+B0DY~6 
...)))) 


0 ) !!!!!!!! 

The /:GEN found nothing in this case, so time domain gets no 
votes. 

(Checking CONTAINment took a long time, as the row of "!’s" 
attests. This is a typica.l example of the slowness of STP 
on a straightforward problem in which it did absolutely no 
combinatorial search.) 


{This rule also ended up with nothing: 

(RECORDING (:GEN (NOT (AND (:SUBTASK (DEN ...) ?SUP /V 6) 

(:TASK-ACTION ?SUP~6 (D-EXPLODE ?+P A 6)) 

(:- (:ENAB-STATUS PSUP^G) 

. ACTIVE) 

(0-FEATURE 7+?^ [RANGER FREQ-OP VERY-HIGH]))) 
(:RULE-OUT 0PT#411)] 

0) 


;So the vote for frequency-domain is decisive... 

(CHOICE CHOICER 10 DONE) 

(TASK (T11379/2395) REDUCED TO 
[FREQ-DOMAIN-REPHRASE 

[(LAMBDA (IN) (AND (PERIODIC ... 0.001) (FORALL ...)))] 
[(LAMBDA (IN OUT) U (TFUN ...) (LAMBDA ...)))]]) 


{...and execution proceeds 

(CREATING TASK (: TASK G0241 <> (LAMBDA NIL 


<>]) 

(ENABLED [G0241D 
(EXECUTING [G0241]...) 

(TASK [G0241] BEING REDUCED) ! 
(TASK [G0241] REDUCED TO 

(:SEQ (:FIND (LAMBDA (+FPT) 


(FREQ-DOMAIN-REPHRASE [(LAMBDA ...)] 
[(LAMBDA ...)])) 
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(EXISTS (FP1 FP2 FPT) 

(FORALL (SI S2) (IMPLIES ...))))) 

(LAflBDA (FPT) (:INFER ’(SIG-FEATURE ...) <>)))) 

: The plan is to find frequency pictures and compare them..., 

(CREATING TASK (: TASK ITASK//414 <> (LAMBDA NIL 

(:FIND (LAMBDA (+FPT) 

(EXISTS (FP1 FP2 FPT) 
(FORALL ...))))) 


<’ (FPT#413)>]) 


;... then infer signal features. (See <*FREQ-D0M-REPH-D0-1>.) 
(CREATING TASK (: TASK MTASK0423 <’(FPT#413)> 

(LAMBDA (FPT) 

(:INFER ’(SIG-FEATURE ...) 


<>)) 


<>)) 

(ENABLED (ITASK#4141) ! 


(BLOCKED (MTASK#423J) 
(EXECUTING (I TASK0414]...) 
(TASK tlTASK#414] PRIMITIVE) 


;/:FIND is the user’s way of calling STP. 

;Here is what the STP trace looks like for this problem: 

(STP TRACE 1 0 (NOT (IMPLIES (AND (IS SIGNAL SI 1433/3330) 

(AND (PERIODIC (TFUN ...) 

0 . 001 ) 

(AND (IMPLIES ...) (IMPLIES ...))) 
(IS SIGNAL S21434/3330) 

(- (TFUN S21434/3330) 

(LAMBDA (T) 

(SIN ...)))) 

(AND (=> ’(FREQ-PICTURE ...) 

?FP1) 

(=> ’(FREQ-PICTURE ...) ?FP2) 

(FREQ-PIC-TRANS ?FP1 ?FP2 
?FPT) 

(-> ’(DEN ...) ?FPT)))J 

NIL) !!!! 

Unfortunately, a bug in a very tow-level routine caused an infinite 


recursion in the midst of this attempted proof. Therefore, the system never 
got to the point of actually generating or comparing frequency pictures. 
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V.B.3 NOAH in NASL 

Jon Doyle and I have done 9ome preliminary experiments toward a "free 
translation" of Earl Sacerdoti’s (1975) NOAH program into NASL. As 1 
discussed in Chapter I, NOAH and NASL are based on rather different 
presuppositions, so an exact translation would be somewhat contrived. NOAH is 
organized around repetitive execution of a strict sequence of 9teps of the 
form, "Expand the plan; criticize it." After the plan has been entirely 
reduced to primitives, it is executed. In carrying out these steps, the NOAH 
system assumes that all actions’ effects are fully computable in advance; it 
reasons confidently about future states of the world. This assumption is 
false for many of the actions NASL tries to accomplish. 

Nonetheless, the parallels between the two systems are tempting. Lie 
wondered if it was possible to encode NOAH "critics" as NASL "policies." The 

critics we concentrated on were "Resolve Conflicts," which orders actions to 

« 

prevent one from undoing the prerequesi tes of another; and "Eliminate 
Redundant Preconditions," which attempts to prevent the same action being done 
tw ice for two different reasons. 

Ue have done some preliminary coding (it only takes about 5 pages of NASL 
expressions), but the unsettled state of the interpreter has made this mainly 
a G edanken experiment. The results so far are mixed. On the one hand, it 
takes very little effort to express as deductive "mini-theories" much of what 
is meant by concepts like "prerequisite" in a system like Sacerdoti’s which 
has them built in. 

On the other hand, we had some disappointments. It is more difficult than 
I had hoped to distinguish problem reduction from execution. NASL assumes 
that a network can be executed as soon as it is generated; to force it to be 
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more NOAH-like requires the user to write explicitly the theory of elaboration 
levels that is apparently built into the NOAH elaborate-criticize loop. The 
user must explicitly tell the system to postpone execution of lower levels 
until higher levels are reduced. In principle, there is nothing wrong with 
having to do this, since this i3 just another mini-theory. Uhat made us a bit 
squeamish about it was the necessity of ignoring altogether NASL's use of 
/:MAIN tasks (Sect. II.B.l) in specifying what happens during task reduction, 
and replacing it with an explicit theory of /jSUCCESSOR relations. 

I think it is fair to conclude from this "experiment" that NASL is an 
worthwhile alternative to NOAH, especially for problems where there is much 
user-supplied knowledge about plans, and only incomplete foreknowledge of the 
effects of the basic actions. 


IT 
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VI Conclusions 

"Thi9 ... may seem trivial, 
but I think it is not without importance." 

— Mary Uarnock, Ethics since 1900 

I set out to construct a circuit designer so flexibly organized that it 
could respond to all relevant aspects of a design problem, yet directed enough 
to be efficient during its normal operation. I implemented a rule-based 
problem 9olver called NASL and have done preliminary experiments using as my 
main vehicle DESI and ZORCH, sets of rules embodying theories of design and 
electronics. The results are consistent with the hypothesis that the 
organization of NASL has the right kinds of power. As uith many experiments 
in AI, the results are not unequivocal. Our conclusions rest largely on 
esthetic considerations. 

The theories of design and electronics drew heavily on previous work by 
others. (Freeman and Newell, 1971, Stallman and Sussman, 197S, A. Brown, 1975) 
There are novel elements. The design process embodies a modified top-down 
strategy. Domain-dependent information, expressed in a modular way, orders 
design choices and controls their interaction. Uhen the top-down elaboration 
reaches the level of canned "device schemata," the task structures stored 
there become integrated with it. The theories embodied in the programs that 
make this happen are further steps toward competing with human performance in 
these areas. 

NASL has severe limitations. Due to limited time, I uas unable to develop 
many domain-independent control features, because they were not needed for 
electronic design. (Some of these limits were encountered in our attempt to 
study NOAH with NASL. See Chapter V.) The logics of time and belief are 
practically absent. Hence, I cannot claim that the current system could be 
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ju3t as easily used, e.g., to understand stories. Even some features 
important to electronic design, such as describing and correcting mistakes, 
could not be implemented in the time I had. 

Second, the system’s flexibility in principle is offset by its lack of 
patience and skepticism in assimilating what it hears. An untrained user 
could bring its operation to a halt by telling it the urong things. 

I have had some disappointing failures. The program is too big and slot) 
to be practical, apparently because of the implementation of data-base 
operations, rather than because of any combinatorial explosion, flore 
substantively, the division of labor between theorem prover and interpreter is 
in many ways wrong. The decision to use predicate calculus for representing 
and using knowledge was the major theoretical gamble in NASL’s design. This 
gamble has had wildly equivocal results. 

The style of knowledge encoding encouraged by NASL is, in my opinion, 
quite exciting. These features in particular stand out: 

> All control information is explicitly represented in the data base. 

> Host dependency information is automatically gathered by the system in a 
complete and convenient way. 

> Plans can be described incrementally. Specification of order and choice 
depends on rules which can be combined in flexible ways. 

> Predicate calculus is used a3 the notation for control and physical 
information. 

I will discuss first my successes, then my failures, and which way 
research might go to overcome the limitations I have discovered. 
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VI.A Successes 

In this section I want to put the NASL system in perspective, and argue 
that it is a step toward understanding mental functions. Fig. VI. 1 shows a 
map of current ar t i ficial-intelIigence research. It may also be taken as a 
map of mental functions, with the arrows taken as indicating the flow of 
information. Either way, the central box with the question mark is a major 
mystery. He know that this center is concerned with "understanding," "problem 
solving," and "learning," and we knou that it contains many sub-boxes. Much 
of mainstream AI is concerned with the somewhat speculative pastime of 
proposing and testing pieces of this box. 



VI Conclusions 


181 



Figure VI. 1 Provinces of Artificial Intelligence 
The thesis that rule-driven problem solving is an important technique 
depends, I think, on a picture of the mystery box like that of Fig. VI.2. 
Normal cogitation is performed by a problem solver accessing a data base of 
rules. Neu rules are created by a rule generator; the most direct way is by 
translation from natural-language statements. The rules are not guaranteed 
"correct"; they must be revised if faulty by a debugger. (McDermott, 1974a, 
Sussman, 1975) 
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Figure VI.2 The Rule-Based Utopia 

To some degree, putting these last tuo functions in neat boxes is wishful 
doodling, but the problem-solver box is intended to be real. The NASL system, 
or some future descendent, resides in this box. To what degree do features of 
NASL support progress on the rule-driven paradigm? In answering this 
question, I will survey in detail what I consider the strengths of the current 
system. 

NASL is driven by a general predicate calculus that supports backward and 
forward deduction. This feature forces the user to think in terms of truth 
and falsehood, rather than in terms of, e.g., "demonic action." For example 
(see Chapter II), there is no way to "deduce the erasure" of a formula. 

Unlike a PLANNER-type system (Hewitt, 1972), NASL treats erasure entirely 
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differently from recording. This enables more revealing records to he kept. 

It forces the user to think in terms of true rules rather than apparently 
useful ones, like productions, which might have to be changed later, or might 
introduce arbitrary symbols with no presumed meaning. IRychener, 197G, Newell, 
1971) Th ‘13 half of Minsky’s (1974) "monotonicity" problem is no problem at 

all, but a valuable kind of discipline. 

The notational power of the predicate calculus strikes me as a tool we 
cannot do without. Much of this power depends on providing a good vocabulary; 
and, in the realm of control structure, I have done this. But the notation 
itself is good, in my experience, independently of what it is talking about. 

It allows you to think in terms of statements with truth values, its treatment 
of quantifiers doesn’t cramp your style, it provides powerful and natural 
pattern matching, and it forces you to say what you mean. 

This formal freedom is necessary to to support restrictions on the 
substance of rules. NASL formulas are not restricted to talking about 
clinical parameters or values of physical quantities in a network, but they 
are restricted (for practical purposes) in the way they talk about concepts 
like action, decision, policy, and problem transformation. In order to get 
something done in NASL, you must express yourself in terms of tasks, "rule-ins 
and rule-outs," rephrasing actions, etc. The task language is restricted to 
such a degree (there being no real loops, gotos, or conditionals) that many 
things can be done only via these mechanisms. 

These conventions enforce "intelligibility" at a useful level. At every 
step, the system knows by way of quite shallou deductions almost everything 
there is to know about what it is doing, what its future tasks are, uhy it 
chose to do what it did, etc. This knowledge is used heavily in the rules for 
choosing, rephrasing, and mistake correction. Because the number of innate 
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concepts has deliberately been allowed to grow, shallow deductions are 
possible and required; NASL does not have or need a theory of "program 
understanding." (Ualdinger and Levitt, 1974) I believe this property is 
essential to an intelligent program; it is no accident that the average person 
is a good planner and a bad programmer. 

A most important example of this reliance on innate control concepts is 
the notion of "frozen tasks" which is so useful in the representation of 
device schemata. (Chapter III) The instantiation of such a schema causes 
information regarding the purposes of components to be activated, in the same 
notation that is used for expressing explicit goals. These old tasks then 
interact with new ones in determing the solution. In this way, DES1 exhibits 
"machinomorphi sm." The purpose of a circuit is expressed as a frozen purpose 
of the machine. No new concept need9 to be introduced, and the problem of 
relating the special-purpose teleology of each domain to the machine’s concept 
of its own purposes is avoided. 

This organization of predicate calculus plus large innate vocabulary is 
potentially of great value to the Rule Debugger module of Fig. VI.2. It is 
known that debugging a data base requires keeping records of the use of data 
which might be faulty. (McDermott, 1974a, Davi9, 197G) The kinds of records 
kept by NASL, deductive dependencies and task relations, are just the kinds 
required. 

Another powerful organization principle that emerged during this research 
was the notion of "packet." (McDermott, 1975) This device enables NASL to 
represent large chunks of data at a relatively low cost. It is used to 
represent circuit diagrams and sets of related problem-solving rules. 

From a distance, a packet looks like a large chunk of knowledge; up close, 
it looks like many small pieces of knowledge. It may be used to implement 
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frames (Minsky, 1974) in an extensible" way. The knowledge is organized by 
the dependencies I described before, but a new piece of knowledge can always 
be added without immediate fear of interactions. 

This is partly because NASL is organized around the expectation of 
interactions. It expects that occasionally more than one or less than one 
rule will appear relevant. In these circumstances, it enters special 
protocols which first look for relevant higher-level rules, and then ask the 
user to supply them. Much remains to be done in this area. (Good work has 
been done already by Davis (1976).) The results so far indicate that the 
standard feeling that frames’ contents are hopelessly "strongly coupled" (cf. 
Sussman, 1975) is too pessimistic. 

The fact that NASL’s facts come in large chunks of small data has 
implications for the design of the Rule Generator of Fig. VI.2. It is a very 
appealing model of learning by discovery that large bites of information are 
taken at one time, by copying an entire theory from one domain to another. 
(Minsky, in progress) Uhat is nice about rule-based theories in particular is 
that they hint at the next step: altering particular rules that were faultily 
transformed during the "copy," and adding domain-specific interaction 
handlers. 

The kind of chunking that NASL currently supports would not handle this 
kind of learning, but it is suggestive. It might be worth making the effort 
to recast the entire corpus of electronics information as an instantiation of 
a more abstract (and smaller) theory of. say, common-sense physics. If this 
were successful, a start at capturing any similar domain would be to 
reinstantiate this theory in a different uay. 

The conclusions I have draun so far can be summarized as follous: (1) A 
flexible problem solver must have innate concepts of tasks, decisions, and 
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other similar control concepts; (2) predicate calculus is, at present, the 
best language for expression of propositions in these terms; (3) the rules 
expressed in the calculus must be tightly organized, linked by dependencies 
and bundled into packets. 

VI.B Failures 

The next questions are someuhat independent: Is a predicate-calculus 
theorem prover an effective mechanism for retrieval of information expressed 
this way? In particular, can it be interfaced effectively with the 
interpreter that uses it to decide hou to act? With respect to these 
questions, the current version of NASL fails to provide satisfying answers. 

As it stands now, NASL is organized as follows. (See Fig. 1.9.) Control 
resides in the interpreter, which decides what to do and how to do it on the 
basis of (a) forward deduction triggered by plan and model assertions in the 
data pool; (b) backward deduction to find ways of breaking problems down and 
to answer questions in the domain of interest; (c) calls to the choice 
protocol, which consists of a ritual of deductions regarding which 
alternatives are good and which bad; and (d) calls to itself recursively with 
/sREPHRASE tasks (which are restricted to being inferential). The outstanding 
features of this organization are: 

(1) The action system always calls the theorem prover, never vice versa. 

(2) The system contains, in effect, two independent interpreters, one for 
plans, and one for implications (/:C0NSEQ’s and /:ANTEC’s). 

These features distinguish NASL rather sharply from the typical AI languages. 
(Bobrow and Raphael, 1974) 

The strengths of this organization are easy to see. The two interpreters 
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are optimized separately. For example, the theorem prover does not have to 
worry about side effects, so it can re-order conjunctive goals and separate 
goals into classes uhich share variables for backtracking purposes., (See 
Appendix 4.) The interpreter, on the other hand, does no backtracking at all; 
handling a failed action is a problem for the interpreter, not part of its 
solution mechanism. It goes to great trouble to find reasons for its choices, 
rather than just trying one alternative now, and another later if that one 
faiIs. 

These strengths are pleasing, but they do not outweigh the weaknesses, 
which are: 

(1) The same knowledge must sometimes be put in two places, in two 
notations, one for each interpreter. 

^2) The deduction machinery is unable to use information about choice and 
rephrasing. 

(3) Additivity suffers from the user’s uncertainty about which interpreter 
to use. If he guesses wrong, he may have to reorganize his data completely 
when the chickens come home to roost. 

Consider, for example, the notion of equation solving. DESI has a weak 
ability to do this (see Appendix 2 and Chapter III), which could be stronger 
without too much effort. Notice that this information has been expressed as 
an "inferential plan" concerned with rephrasing manipulations of predicates on 
constrained quantities. This seems entirely proper, clear, and elegant. Nou 
consider the following deductive goal: 
t- ( + ?X 3) 5) 

Plainly, this requires exactly the same knowledge. (Cf. Bundy, 1975) 

It would be embarrassing enough to have to put the same information in two 
places, but in fact the situation is even worse: the necessary knowledge 
cannot be given to STP at all! (Uhich is why it appears in an inferential 
rephrasing plan.) It would have to be put into an ad hoc LISP program. 


n 
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Rather than do this, I have tried to make sure that deductive goals of this 
sort never appear. The absence of a choice protocol inside the theorem prover 
hurts just as much. The most embarrassing consequence of this awkwardness is 
that the user must plan his advice a little more carefully than is desirable; 
he must decide what should be expressed as a task and uhat should be expressed 
as a deductive goal on the basis of his knowledge of the theorem prover’s 
limitations; this requires an unacceptable degree of knowledge of the 
program’s internal structure. 

This problem evolved from seemingly innocuous beginnings; what started as 
a single interpreter fissioned. It has been clear from the start nf this work 
(McDermott, 1974b) that the concepts of deduction and action were both going 
to be necessary. As design and implementation proceeded, these two categories 
became more and more closely identified with the independent categories of 
"blind search" and "careful mode," respectively. The theorem prover was 
written with fewer and fewer "careful" features, and more and more general 
optimization of the sort described above, while the action system absorbed the 
cleverness. This organization finally broke down when I realized that several 
sorts of "clever" forward deduction, such as constraint resolution (Stallman 
and Sussman, 197G), would not fit into the framework of a stupid theorem 
prover (STP). The inferential plan was created to fill this gap. It may turn 
out to be the right solution (see below), but if it does it will be an 
accident. 

To some degree this failure is due to sloppy thinking, but I believe the 
problem is more fundamental. The only way to make "careful mode" work is to 
spend time asking and telling yourself what you’re doing. If this asking and 
telling is itself "careful," things become intolerably slou. 

It might look as if asking and telling could be potentially careful, in 
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the sense that they could normally proceed blindly, but, if trouble arises, 
turn themselves into ongoing p I an-1 anguage plans. For example, with the 
conjunctive goal [AND (P ?X) (Q ?X)], if the system "runs into trouble" on [Q 
?X1 , it could turn itself into a plan of the form "Find a P; then verify it is 
a Q, " and use choice and rephrasing on the second subtask. There are two 
problems with this. First, it is not all that easy to decide that you’re in 
trouble. The mere retrieval of tuo rules does not mean that a choice is in 
order; the two rules could be functioning as a COND, or there may be no 
intelligent criterion for selecting one or the other. Indeed, once one has 
the notion that the theorem prover is the locus of "bI ind search," he tends to 
write rule systems of just this sort. However, I believe that the "meta-rule" 
construct of HYCIN (Davis et. al., 1975) would go far toward solving this 
problem cheaply. 

Second, and much more difficult, is that the kind of sequencing done in a 
backtracking theorem prover is just not the same as that in a planner. 
Predicate calculus is a non-deterministic language; it does no good to 
translate it into a formally isomorphic construction in a deterministic 
language. Put another way, NASL is intelligible because many unintelligible 
constructs have been covered by deduction or other built-in protocols: "map" 
loops like those in LISP are done by generating items deductively and 
generating a (sub) task for each; many search loops are done by finding one 
such item; the choice protocol is a priceless piece of "canned loop" which 
replaces specialized discrimination nets. To ask that any of these constructs 
be translatable when necessary into NASL plans is to destroy this 
intelligibility. 

The situation is not hopeless; I have just learned less about this aspect 
than I had hoped. Here are two possible routes for avoiding this problem: 
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(1) Elevate this disorganization to the status of a theoretical conjecture 
that "deductive information retrieval" is a separable activity that never 
requires anything as complicated as solving an equation or rephrasing a goal. 
(This is part of uhat R. Hoore (197S) and Fahlman (1975) have been urging.) 
Inferential plans would be retained for these complex tasks. 

(2) Provide deductive protocols analogous to those used by NASL. Dispense 
with inferential plans. This will require careful identification of 
situations where the protocol would be worth it (such as: choosing among 
answers to a conjunctive goal, ordering conjuncts, choosing splits, ordering 
implications to apply); and a way of efficiently noticing when there are no 
applicable rules, in which case brute-force deduction is to be used. 

The substantive difference between these alternatives is that alternative (1) 

makes complex inference a kind of task, and hence deterministic, saving search 

for the stupid theorem prover; while alternative (2) makes even complex 

inference subject to backtracking, which is modified by the application of 

rules. 


VI.C Further Work 


Let me list, in order of increasing difficulty, projects that are worth 
doing to extend this research. Some of them I may do myself. 

(1) Encode more electronics knowledge. The gaps in ZORCH are described at 
the end of Chapter III. 

(2) Speed the system up. The system can undoubtably be made much faster 
by abandoning some of my more elegant programming techniques. 

(3) Implement the error-handling machinery I described in Chapters II and 
III. This will require careful reconsideration of data dependencies. 

(4) Unleash the logical calculus. There are restrictions on NASL’s 
generality which I believe are due mainly to inadequate implementation of the 
logical calculus. There are many domains which are beyond its grasp because 
it lacks a notation for things like time, belief, and the actions and beliefs 
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of other people. To some degree these areas could be handled by the use of 
modal reference points for time intervals and other people's minds. The 
system could simulate other persons’ thought processes with its own theorem 
prover, and avoid some of the problems associated with epistemic logic. 
(Hintikka, 19G2) Broadening the syntax of "/jTASK" to include an agent slot 
would be a step toward representing other persons’ purposes; the interpreter 
could use itself to simulate them as a way of understanding their actions. 

(Cf. McDermott, 1974a) However, there is an "abductive" component to such 
reasoning (Pople, 1973, Schank, 1975, Lehnert, 1975) that is beyond the 
capability of NASL without more substantive revision. 

(5) Endow the system with more "patience and skepticism." The greatest 
ueakness of NASL as it now stands is its credulity. It accepts wrong rules 
(even syntactically wrong ones) as readily as right ones. This is 
unsatisfactory for a system which already understands its domain thoroughly; 
surely one task it should be able to carry out is to estimate the plausibility 
of a new rule in the presence of its old ones. 

In some simple cases, a new formula may be disproved. In that case, the 
syftem would be in an excellent position to claim that something was wrong. 
Unfortunately, this is not likely to happen very often. The less important 
reason for this is that STP is not built to do interesting proofs. The more 
important reason is that many theorems have conclusions defined only 
pragmatically, by their meaning to the NASL interpreter. These are the 
formulas of the form "A1 and A2 and ... and Ak imply C," where C is in terms 
of concepts having to do with choosing (e.g., "/:RULE-IN") or acting (e.g., 
"/:TASK"). These concepts are in a sense primitive; we want to define "good" 
and "feasible" in terms of these concepts rather than vice versa. Thus, I 
said that [/:T0-D0 |task| |action| |outputs| |method|] meant, among other 
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things, that the method was an effective, feasible, and permitted way of 
carrying out the task. But, since there '19 no independent theory of these 
concepts, a /:T0-D0 implication cannot, except in the most trivial cases, he 
disproved by showing its method would not be permitted (or feasible or 
effective) under the circumstances. Still another problem is that a typical 
conditional of this sort is counter factual; one of the antecedents is probably 
false at the time the rule is heard, making a proof trivial. To disprove this 
rule, the system would have to prove a modal theorem to the effect that "there 
exists a ‘possible world* in which the antecedents are true and the consequent 
false." 

The solution to these problems is to integrate the theory of action 
failure with the theory of assimilation of new information. In the early 
stages, this will be probably require the co-operation of a human friend. 
(Shortliffe, 1976) The idea is to place a new formula or set of formulas on 
"probation." (McDermott, 1974a) Uhen a contradiction, action failure, or 
inability to choose occurs, the system will check the formulas involved to see 
which are on probation and might contain errors. The idea is to see how 
things would work out differently if the formula were not there. If, for 
example, a choice fails because all alternatives are eliminated, and there is 
a formula on probation involved whose absence would have left some 
alternatives in, the system is justified in asking for clarification of the 
new rule. 

Notice that this requires an "advice-taking protocol" for each class of 
rules, that is, for each pragmatic predicate the system knows. It would be 
attractive if these were plan networks; and if the advice-taking actions in 
certain circumstances could be framed as policies. 

(6) Add a natural-language interface. This is difficult in itself, and. 
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Appendix 1 -- NASL Syntax and Informal Semantics 

A formula is an S-expression enclosed in [brackets]. Redundant 
parentheses may be dropped. Thus [US RESISTOR R#21)l is written US RESISTOR 

R#21]. 

The leftmost element of a formula or subpattern is its function. Functions 
with range I true, false I are predicates. The Boolean functions AND, OR. 
IMPLIES, and NOT operate on truth values. 

Besides functions and their arguments, there are "variable binders" whose 
job is to indicate the names and uses of variables in formulas. These are the 
universal quantifier FORALL, the existential quantifier EXISTS, and LAMBDA, 
which defines functions and is used for all other variable-binding chores. 
(Lambda may be typed as "\" ("backslash") to my LISP system. I will use this 
symbol instead of "A" throughout the appendices.) Thus thp following are NASL 
expressions: 

[FORALL (X) (EXISTS (Y) (LOVES ?X ?Y))] 

[FORALL (X) (SATISFIES ?X 

(\ (Y) (EXISTS (Z) (P ?X ?Y ?Z) )>)] 

Variables are flagged with a "?" where used, but not where bound. 

Many variables are not bound at all. As in most predicate calculus- 
oriented systems, all formulas are Skolemized (Nilsson, 1971) before being put 
in the data base, so that there are no quantifiers at the "top level" of an 
expression. (Expressions remain quantified inside lambda expressions and as 
arguments to function.) Free (universally quantified) variables remain 
prefixed with a question mark. A "skolem form" represents an existentially 
quantified variable. Skolem forms look like 

[SK |var| |id number| -dominating uni versa Is-1. 

For example, [FORALL (X) (EXISTS (Y) (LOVES ?X ?Y))3 is internally represented 
as [LOVES ?X (SK Y 70 ?X)) ; while (EXISTS (Y) (FORALL (X) (LOVES ?X ?Y))I is 
represented as [LOVES ?X (SK Y 71)]. The program generally abbreviates the 
general skolem form to "|var|!|id number|" on output; e.g., (SK Y 70 ?X) is 
printed Y!70. I occasionally use this loose notation. (To avoid collision, a 
hash number derived from the skolem-form arguments is usually printed 
following the variable.) 

Because quantifiers are retained inside lambda expressions, the example of 
a lambda expression above is skolemized to 

[SATISFIES ?X (\ (Y) (EXISTS (Z) (P ?X ?Y ?Z) ))] 

An important concept in predicate-calculus systems is matching, or 
unification, of two formulas. (Robinson, 19G5) Two formulas are said to match 
if there is a substitution for their variables which makes them equal. The 
variables are to be imagined subscripted with the name of the formulas they 
came from, to avoid confusion. Thus [P ?X (F ?V)] matches [P (F ?X) ?X) with 
the substitution 


Xj -* (F (F ?V 1 ) 3 
X 2 - [F ?Vj] 
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Internally, substitutions and subscripts are handled using a method derived 
from (Boyer and floore, 1972), (See Appendix 4.) 

There are two special cases of matching. Fj subsumes F z , i f F z i s equal 
to the result of performing a substitution on F v Fj and F £ are variants if 
they subsume each other; alternatively, if renaming the variables of f, makes 
it equal to F^. 1 


to the operation of the deductive system. 


IP (\ (U V) (F ?U ?U)) 3 
without prodding. (See 
-» t\ (X) (G (H ?X ?X)) 3 
The language allows 


Thus [ABSENT 
is one of two 
(I t may be 


These concepts are essential 
(Appendix 4.) 

The matcher is not intended to be a complete unification algorithm for 
nth-order logic, typed ^-calculus logic, etc. A lambda expression will match 
another lambda expression if their variables differ only in name. Of course, 
free variables may not become bound to fragments of lambda expressions 
containing bound variables. Thus [P (\ (X Y) (F ?X (G ?Y))) 3 will not match 

The matcher will not create lambda-expressions 
below.) Thus, [?F A] doesn’t match [G (HA A)) with F 
or any of the alternatives. 

- - formulas to refer to other formulas. 

(BROUN C0U#22J] expresses a property of [BROUN C0U#22I. This 
ways in which NASL expressions may refer to other expressions, 
considered equivalent to, but more convenient than, the use of Goede I numbers 
of formulas.) It has the following variants. First, every user-defined 
formula has an atomic name. (See the description of DEFMLA in Appendix 2.) If 
Fr1LA#99 is the name of [BROUN C0U#22I, we may write [ABSENT FHLA#93] . Second, 
an embedded formula may have variable parts, called escape Forms, which are 
prefixed by _ ; this indicates that the value of the prefixed expression 
(which should be a formula) is to be used to construct the formula. For 

if FUN is 3 function that maps a formula into its first subformula, 
(F00 [BAR _(FUN [FA]))) - [F00 (BAR F] ]. Escape forms are most useful in 
conjunct'on with variables. Thus [F00 (BAR _?Ff1LA] I says, "For all formulas 
('rrlLA, the formula obtaiTied by making the pattern of 7FI1LA the argument of BAR 
has property F00. (Each such embedded formula is equivalent to some open 
term, such that substituting Goedel numbers for its free variables gives a 
closed term whose value is a Goedel number.) 

(latching embedded formulas against formulas with escaped variables is a 
way of decomposing formulas. This is used by some of the "meta-systems" of 
NASL. For example, the result of matching [P [F00 _?X3] against [P [F00 BAR]] 
19 the substitution X -* [ [F00 BAR]]. 

For ease of manipulation of formulas, the pr 
understood by STP to map formulas onto what they 
C+ 5 5] . One convention I use is that variables 
with the character " + "• thus ?+X might designate 
[F00] . This is purely a convention and not part 

Notice that all NASL formulas in this paper are surrounded^by [brackets]. 
For example, in the result of matching [P ?X] against (P (F00 BAR)], I write, 

?X has value [F00 BAR]," even though ?X was originally matched against a 
subpattern without brackets. This enables you to tell unambiguously which 
formulas are being used and which quoted. (Actually, uhen it comes to atomic 
symbols, I rarely make the distinction between a symbol and a formula. 1 
allow myself to drop the brackets in a formula like CF003.) 

The "sense" construct using single quote is the second way in which NASL 
expressions may refer to other NASL expressions. It allows one to refer to 
the meaning" of an expression and not its value. For example, even if. the 
value of [- NIXON PRESIDENT] is false, [POSSIBLY ’(- NIXON PRESIDENT)] may be 
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imitive function PEN is 
denote. Thus (DEN [+ 5 
ranging over formulas start 
[ [F00]] and ?X designate 
of the language. 


II 
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true. 

Substitution of equals is, of course, prohibited inside any embedded 
formula or sense. 

The operator POSSIBLY is an example of a modal predicate. (Hughes and 
Cressuell, 1972, Bressan, 1972) The basic system-supported modal operator is 
[T |reference-point| |pattern|], meaning the value of pattern in "possible 
world" reference-point. (Prior, 19B7) The second argument is implicitly 
quoted. Thus [T (1970) PRESIDENT] would have value NIXON; and IT (1970) (*> 
NIXON PRESIDENT)) would have value true. 

NASL contains tuples like those of QA4 (Rulifson et. a7., 1972). They are 
represented using <angle brackets>. Within a tuple, the prefix "•#" means 
that the value of what follows is to be considered spliced in instead of 
substituted directly. Such an expression is called a segment form. For 
example, if (F00 BAR] - [<A B C>], t<P (F00 BAR) Q !#(F00 BAR) R>) = (<P <A 0 
C> Q A B C R>] . A similar notation, is used inside embedded formulas. 

If (WHIZ BANG] - I<(A] IB) CC)>], tfP l/MUHIZ BANG) Q]] = IIP A B C Q)I. 

Segment forms make matching more complicated. Strictly speaking, these 
two formulas 

CP < !#?X !#?Y>] and (P <A B>] 
should match three ways 

(X -> [<>], Y - [<A B>]|, 

(X - [<A>], Y -* [<B>]), 

and (X -» [<A B>], Y -+ [<>]). 

My matcher is too lazy. Occasionally this means deductive formulas have to be 
framed in terms of list operations instead of in the most concise style. 


Semantics 

While I am in sympathy with Hayes’s (1974) contention that the semantics 
of a representat i on is very important, the subject seems much too complicated 
for practical representation schemes. NASL is a modal calculus, which should 
have an attractive model theory like Bressan’s (1972). However, operators 
like "CONSISTENTLY" ruin it. Furthermore, there is a pragmatic component to 
many predicates which could not be expressed model theoretically. For 
example, "/:C0NSEQ" and "/:ANTEC" both mean "OR," but they are used in 
different ways. Consequently, the most precise description of the meaning of 
the language is a description of STP (Appendix 4) to account for the strictly 
semantic "meaning" of a symbol; and the following index of pragmatic 
predicates with an informal description of the pragmatic meaning the.system 
assigns to each one. 

Here is a list of built-in, pragmatic predicates, with an informal 
description of each. 
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Predicates and Functions with Meanings to the Interpreter 

Task Specification and Relation 

t/:TASK |name| < -input pvars- > 

(\ ( -vars- ) |action|) 

< -output pvars- >] 

means task name, which consists of doing action with the values of the 
input pvars substituted for the lambda-variables, is worth doing. It will 
produce output values to be bound to the output pvars. 

[/: SUBTASK | task name 1| | task name 213 





Those re 


—nt-statue SUBS-ENABLED dnd V 
status SUCCS-ENABLED. These assertions may 
flow of control. 


,, I* I® ", 1 

IC.U therefore be used to direct 


[/..TASK-STATUS | task name|3 
[/:ENAB-STATUS |task name J 
[/: TASK-ACT I ON |task name| |action|J 
[/:REDUCED 1 task name13 

a task a, ^cussed in Bed. U.B.!, 

t/j SCOPE 7 1 secondary task "j “ poliiy task has begun it >s 

finished with a /.FINISH task. (See below.) 

Pr imi t Wes 


[/•MOD-MAN IP | task name | |action| |deletehst| | add I i st | 

[/iMONITOR Iformulal (\ <M> |act,on| » 

[/:SET * (express.on| l va, “® 1 . , mittve3 . /..MOO-tlANlP defines the 

These are the non-macro uorldly P /.MONITOR creates a policy of 

•letelist and addlist of the given ac * R ■ th the given action, 

ioling for the erasure of formula and f the erasing.) /:SET i s used 

rhe variable v will be bound to the ta should be a model quantity 

□"change on se, the value o, the -press "• h s s,^ 8upp0rtet , a, though 
ike voltage or resistance, not a pvar. 
hey were model manipulations. 


[/•INFER ’Iproposition| < -task names- >1 
[/.FIND (\ Clvjl ••• |v n D !exPl>J -> <IP V 1> - ,Pn ' 


1/ •' ' ’ • I • 

M.ciwn_ii I Inrooertull 
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are assigned to the pvars. If a choice of ansuers is required, this will he 
reflected in the data-dependency supporting these values. /:FIND-ALL takes a 
property of one argument, and returns a tuple of all the objects which satisfy 
it. /:EVAL calls the evaluator and returns the value. 

/:INFER is used to write special inference rules. The proposition given 
is recorded, supported by the propositions recorded by the specified task 
names. For example, the following task net does the obvious 

[/: TASK MINOR <> (\ () (/-.FIND (\ 0 (MAN SOCRATES)))) <>) 

I/:TASK MAJOR <> 

(\ 0 (/:FIND (\ 0 (IMPLIES (MAN ?X) (MORTAL ?X))))) <>) 
t/:TASK CONCLUSION <> 

(\ 0 (/'.INFER ’(MORTAL SOCRATES) <MIN0R MAJ0R>)) <>) 


or 


t/:OUTPUT < -vals- >] ==> < -nygrs- > 

i/ifflin ]t r |] 

♦BEGUN actions type should be one of ♦FINISHED *SFTIJP 

♦BEGUN. ♦FINISHED means the action is done; ♦SETUP means the 

po i'cu whos 6 SUCCeSSOrs m3y now be enabled! ♦BEGUN means the action iTa ' 9 3 

/•iu?Puf?rnke C !/ 5 .miM^F,N?^m en fl ed mt J'- ! he policsi is /iFIN| SHr-0. 

to be node pvar values. Thus, ,he lask tn”" Vi " UeS 

sets !(pj?n t (F °?i <,{ ^ V1)> (V) ^'OUTPUT <?V>) ) <MPV2)>] 

to the value of t(PVl)] when it becomes available. 

(/{CONTINUE |task name| |action 13 
(/sFINISH |task name| jaction13 

sub l?*l ITVIT a .° U3e " '° con,r °' “hen all (he primary 

created as a sub alik Y?!! PS Y 6 been fished, a /:FINISH task ui I I be 
reduce i t The ° ? policy; it i s up to the user to supply rules to 

task! lactiJuT ♦ T a,3 ° execute actions of the form (/.-CONTINUE |policy- 
II?B.l.) ' Pe ^ mterm ' ttent elution of the policy. (See Sect. 


Macro Primitives 


|super task)] 
used in attaching 


(/:DO-SUBNET |plan schema| |vars mapII 

; : ^-! NSTANCE |plan instance l IP I an schema | 
t/:MAIN |sub task| |supertask|] 

As explained in Chapter II, these formulas are 
standardized subnetworks to the current plan. 

{ -vars- ) |act ion 21 )) 

r/ : n2n K n*f Ct . ion 1 • (X ( ~ vars - ) < -actions- > )] 

r/nn All ' pr,mary action| < -secondary actions- >] 

1/:UU-ALL < -actions- > |action|] 

a nlt^nf * acr ? 8 ® lab ° rate into various standard structures. /:SEQ turns into 

of thP P °h I, firSt ° f WhiGh feed3 pvars to the seconc) : the outputs 
it sets un T „ ° Utputs 0f the /:SEQ ' /^ORK produces no pvar values; 
other tasks Th 3 af r ac ! 1 on ’ act j ° n 1 be *"g the predecessor of each of the 

/•WHILE starts a?| V ^ U6S ! P 18 ° UtpUts are fed to the successor tasks, 
the taL ! L secondary actions as policy tasks with /:SC.0PE equal tc 

the task for the pr.mary action. /:DO-ALL carries out all the actions in no 
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particular order, outputting the values of action’s pvars. 
Task Reduct ion 


[/:TO-DO |task name 
means, "action 2 is 
task named which consi 
formulas of this kind 


I laction 1| |output pvars| laction 2|J 
an effective, permitted, and feasible way of doing the 
sts of action 1 and outputs the given pvars." Deducing 
is the first resort in reducing problematic tasks. 


/: 

/: 


[/:REPHRASE |task name| 
This action, which must 
TO-DO deduction fails. 
REDUCED. 


laction formula| |output pvars|] 
be reduced by user-supplied rules, is set up 
See Sect. II.C.2. Its object is to leave the 


when 

task 


Predicates with Meanings to the Choice Protocol 

[/:CHOICE |choice name| |context| |formula|] 

means a task or the executive (context) requires a choice regarding answers 
to formula. The choices are recorded by formulas like 

[/:OPTION Ichoice name| |option name| |answer|] 

I/:RULE-OUT |option|] 

t/:RULE-IN |option|] 

[/:RULE-TOGETHER < -options- > |new formula)] 

These three kinds of formulas are looked for repeatedly, in this order on 
each pass So, for example, if a formula is /:RULED-OUT before the /.-RULE-IN 
rules are looked at, it has lost its chance. See Sect. II.C.l. 

[/:QUIESCENCE |cho ice name|] 

is recorded when no activity occurred on a choice cycle. It is used to 
cause further forward deduction of /.-RULE statements. 


Functions and Predicates DeFined by Built-in Axioms 

IELT |x| |tuple)] means x is an element of the tuple. 

ISET-OF-ALL |prop|] denotes the set of all objects with the property 

prop. 

[flAPCAR |f | | tuple | ] denotes the tuple obtained by applying f to 

every element of the tuple. 

[DEL |x| )t up Ie|] denotes the tuple obtained by deleting the first 

occurrence of x from tuple. 

[SUBTUP | tup 11 |tup 213 means every element of tuple 1 is an 

element of tuple 2. 

[CONTAINS | formula 1| | formula 2|] is true if formula 2 occurs 

somewhere inside formula 1 (as a proper 
subexpression). 

^ formuial) true of atomic-symbol formula like [(A)) 

‘l" i^-VAR | f ormu I a |) true of formula of variable, like [ [?X] ] 

[DEN | formula|] strips a layer of brackets off formula. (See above.) 

[/:- Ix| |y|J true if x and y match; else assumed false. 


II 
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[« |x| |y11 true if x and y designate the same thing. To test 

this, the system first tries matching, 
then evaluating [via "«/>") x and y 
and trying the match again. 

[PRESUMABLY ’(proposition| |use|I if true, may assume the 

proposition from inability to disprove it. 

(See Sect. 11.B.2.) 

[X0R1 |pat| < -propositions- >] means exactly one of the propositions 

is true if the pattern is. E.g., 

[X0R1 (LIVING ?X) 

<(ANIMAL ?X) (VEGETABLE ?X)>] 

[NFUN |n| |f|] denotes a function of n arguments which makes a list 

of them and applies f to it. E.g., 

[NFUN 3 (\ (L) (+ !#?L) )I 
- [\ (X Y Z) (+ ?X ?Y ?Z)J 

[+ -args-] [- |x| |y|] [* -args-I [// |x| |y|] 

arithmetic functions. These are simplified by built-in LISP functions 
called by the evaluator. 

[/< |x| |y11 [/> |x| |y11 [-/< |x| |y|] [/>- |x| |y|] 

arithmetic inequalities 


Predicates with Meanings to the Theorem Prover 

Pragmatic versions of "OR": 

[/sCONSEQ |p| |g|] 

[/:ANTEC |p| |g|I 

[/:GEN |p| |Q|] 

The first two are used during backuard chaining (a call to STP). The 
second is also used during forward chaining (a call to RECORD). /:GEN is 
really a call to STP in the midst of forward chaining. See Sect. II.B.2. 

[/:PKT |name| Ipacket vars| -conjuncts-I 

Like [AND -conjuncts-I, but indexed differently, and more efficiently if 
most of the conjuncts wi I I never be referenced. 

[=/> ’|Ief 11 |right| I 

means [= | left) |right|I, but it also means that any expression subsumed by 
left should be replaced by right wherever it appears (except inside a quoted 
expression). In practice, this replacement is done mainly in newly detached 
deductive conclusions. 

[/•.CONSISTENTLY ’ |proposi t ion|I 

is true iff the proposition cannot be refuted by STP in the current data 
base. If the proposition has free variables, they will be converted to Skolem 
forms before trying the refutation. 
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[/:DD |supporter| |path| < -supporters- > |supportee|] 

[/:SUPPORT < -supporters- > |supportee|] 

^ are usec * to access data dependencies as though they were stored in the data 
base. The /:DD formula is true if there is a data dependency linking the 
supporters to the supportee. These are tuple-fied versions of the labeled 
treelets described in Sect. II.D. In particular, the element supporter must 
appear in the supporters treelet, with labels in path. For example, up might 
have 

t/:DO [/:TASK TA607 <> (A () (PUTON A B)) <>] 

<DO-ACT-RESULT> 

<(DD-ACT-RESULT < t/:TASK T#607 <> (A 0 (PUTON A B)) <>]> 

<00-APRI N <M0VE-0EFN»)> 

(ON A BJ] 

/.SUPPORT is simplified version in which the supporters must be just a list of 
deductive supporters. It is equivalent to [FORALL (S) (IMPLIES (ELT ?S < - 
supporters- >) (/:DD ?S <> < -supporters- > |supportee|3)3. 


IT (reference point| |term|J 

IS *|proposition|3 

These are the built-in modalities. The first is the value of term from the 
given reference point; the term is usually a fact uith value true or false. 

IS | f ac 111 means "S begins to be true"; it amounts to a special treatment of 
the data dependency that supports it. 

[FRAME |ref point | < -ref points- >3 

[N |ref point| ’(fact|3 

Computationally efficient ways of using modalities. When the system tries 
a deduction of a T-formula, it will try to smash the reference point to a data 
pool using these formulas. See Sect. II.B.2. 


Predicates with Meanings to the Matcher 


FormuI a Meaning 

[/?/? |sym|3 Inside an embedded formula, matches a variable with 
the symbol sym. 

Example: l[\ (_?+V) (F (/?/? _?+V))J] 
matches [ [\ (X) (F ?X)]J with +V -* [ [X3 3 . 


[ION |n| |k|] 
IK In| |c|J 


The identity function of n args that returns arg k. 
Matches [\ (Xj...X| n |) ?X| k |3 

The constant function of n arg 3 with value c. 

Matches [\ (Xj...X| n j) |c|J 
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[CUP |fun| < -funs- >] 

The composition of fun with the funs. If there are 
n of them, each with tn args, this matches 
C\ (K^...X| m |) (|fun| -args-)], 
where the ith "arg" is of the form 
[ I funj| ?Xj ...?X, m |J. 

Examples: ICMP SIN <?F>] matches [SIN] with F -♦ [ IDN 1 1). 

ICMP F00 <?F1 ?F2>] 

matches [\ IX Y) (F00 (+ ?X ?Y) I- ?Y ?X))1 
with FI -* [+] and F2 - t\ IX Y) I- ?Y ?X)1 


Appendix 2 -- A Listing oF DESI 

This is the current (June 27, 1977) version of the design knowledge. It 
is complete except for the definition of LISP functions defining macro-actions 
like CONFIG. (See Chapter III.) 

In Appendices 2 and 3, NASL formulas are defined and added to the data 
base uith the function DEFfILA, which is someuhat similar to MACLISP’S DEFUN. 
The expression 

(DEFMLA |name| |formula| |destination|] 

names the formula and adds it to the data pool that is the value of 
destination. The destination is optional: if it is absent, the current pool 
CURRENT-DP* will be taken. 


(DEFfILA STASK-DEFN !-/> A (STASK ’TSK ’SUPER ’I ’A ’0) 

(AND (/:TASK ?TSK ’I ’A ?0) 

(/:SUBTASK ’TSK ’SUPER)>J 

GENERAL-DP*) 


(DEFfILA DEVICE-CLASSES 

IX0R1 (IS DEVICE-TYPE ’0) 
<(BASIC-DEV-TYPE ’D) 
(SUPEROROINATE-DEV-TYPE ’0)>I) 



(DEFALA BASIC-DEFN IEQUIV (BASIC-OEV-TYPE ’X) 

(NOT (EXISTS (Y) (SUB-DEV-TYPE ?Y ’X) )))) 


(DEFALA AAIN-OEV-TYPE C-/> A (ARIN-OEV-TYPE ’X ’0T> (DEV-TYPE ’X ?DT)1) 


(DEFALA SUB-DEV-TYPE-1 (-/> A (SUB-DEV-TYPE ’0T1 ’0T2) 

(-/> A (DEV-TYPE ’X ’DTI) 

(OEV-TYPE ’X ?0T2)>1) 
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(DEFMLA BASIC-DEVICE-CLASSES 

IX0R1 (BASIC-DEV-TYPE ?D> 

<(PRINITIVE-DEV-TYPE ?D> 
(COMPOS ITE-DEV-TYPE ?D) 
(IOEAL-OEV-TYPE ?D)>] 
GENERAL-DP*) 


(OEFMLA COMPOSITE-DEVICE-CLASSES 

IXORI (COMPOSITE-OEV-TYPE ?D) 

<(GENERRL-DEV-TYPE ?D) 
(SPECIALIZED-DEV-TYPE ?D)>! 
GENERAL-OP*) 


(OEFMLA GENERAL-DEFN IEQUIV (GENERAL-DEV-TYPE ?X) 

(NOT (EXISTS (Y) (DERIVED ?X ?Y) ))}) 


(OEFMLA SPEC-OEV-TYPE-1 

t-/> A (SPEC-DEV-TYPE ?DT1 ?OT2) 

(-/> A (OEV-TYPE ?X ?OTI) (OEV-TYPE ?X ?DT2))I) 

(OEFMLA SPEC-DEV-TYPE-2 

[-/> A (DERIVED ?OTl ?DT2> 

(-/> A (SPEC-DEV-TYPE ?DT2 ?0T3) 

(SPEC-DEV-TYPE ?DT1 ?DT3))I) 


(OEFMLA SPEC-OEV-TYPE-3 

(-/> A (SPEC-DEV-TYPE ?OTi ?0T2) (SPECIALIZED-OEV-TYPE ?DT1)I 
GENERAL-DP*) 


(OEFMLA SOUL-ON-ICE 

t-/> A (DERIVED ?OT >G) 

(-/> A (MAIN-DEV-TYPE n ?OT) 

(AND (HAIN-OEV-TYPE (SOUL 
(-/> C (/:SUBTASK ?T 
</!SUBTASK ?T 


?X) ?G) 

(DEEP-FREEZE (SOUL ?X)>) 
(DEEP-FREEZE ?X)))))J) 


(DEFMLA EASY-DESIGN 

I/iTO-DO ?TSK (OESIGN (\ (X) (OEV-TYPE ?X ?DT) )) <?NRHE> 
(MAKE 7 0T)J) 


(OEFMLA +DESI-1 

[/ :TO-DO ?T (/sREPHRASE ’TSK [DESIGN _?+P) <?DEVNAME>) 

<> 

(/:DO-SUBNET (OESI-REPHRASE-PLRN ?+P ?TSK 2DEVNAME) <>)) 



GENERAL-OP*) 


(OEFMLR +0ESI-2 

[-/> A (/:PLAN-INSTANCE ’PI 

(DESI-REPHRASE-PLAN ’+P ’TSK ’DEVNAME) 

’SUP) 

{-/> A (/: = ?*P [\ (_?+V> _?+8I) 

(ANO 

(/:TASK (EXPLODER ’PI) <> 

<\ () (O-EXPLOOE ’+P>) <>) 

(/:SUBTASK (EXPLODER ’PI) ?SUP> 

</:TASK (ACCOUNT-FOR-ALL ’PI) <> 

(\ 0 (ACCOUNT-FOR-ALL-SHARDS ’+P> ) <>) 

</:SCOPE (ACCOUNT-FOR-ALL ’PI) (EXPLODER ’PI)) 

(/:SUCCESSOR (ACCOUNT-FOR-ALL ’PI) (EXPLODER ’PI)) 

(/:TASK (CORE-FINDER ?PI> <> 

(\ () (/sFIND (\ WOT) 

(CORE-DEV-TYPE ?+P ’+DT)))) 

<’(CORE-DT ’PI)>) 

(/:SUBTASK (CORE-FINDER ’PI) ?SUP) 

(STASK (DAIN-TASK-INFERER ’PI) ’SUP <’(CORE-OT ?PI) 
(\ WOT) (/: INFER 

’(ANO (STASK (MAKER ?TSK) ?TSK <> 

(\ 0 (MAKE (OEM ?+DT)) ) 

<’(WINNER ’TSK)>) 

</:HAIN (MAKER ’TSK) ?TSK)) 

<(CORE-FINDER ’PI)>) ) 

<>) 


(/:SUCCESSOR (MAIN-TASK-INFERER ’PI) 
(SIDE-TASKS-FINDER ’PI)) 


(STASK (SIDE-TASKS-FINDER ’PI) ’SUP <> 

(\ () (/:INFER 

’(FORALL (+ST) 

(-/> G (SIDE-TASK ’+P ’+ST) 

(EXISTS (T) 

(AND (STASK ’T ’TSK 

<’(WINNER ’TSK)> 
(DEN ?+ST) 

<>) 

</:SUCCESSOR 
(MAKER ’TSK) 

?T)) )) ) 

<>) ) 

<>) 


(STASK (FEATURES-FINDER ?PI) ’SUP <> 
(\ () 



(/sINFER 

’ (FORALL (+FT) 

(-/> G (D-FEATURE ?+P ? + FT> 

(EXISTS (T) 

(AND (STASK ?T ?TSK <> 

(\ <> 

(D-NOTE (DEM ?+FT)> ) 
<>) 

(/:SCOPE ?T (HAKER ?TSK)) 
(/:SUCCESSOR 

?T (HAKER ?TSK)>) )) ) 

<>) ) 

<>) 

(STASK (GATHERER ?PI) ?SUP <> 

(\ O (/!INFER ’(/iREOUCEO ?TSK> 

<(CORE-FINDER ?PI> 
(SIOE-TASKS-FINOER ?PI) 
(FERTURES-FINOER ?PI)>) ) 

<>) 


(/!SUCCESSOR 
</!SUCCESSOR 

(/:SUCCESSOR 
(/:SUCCESSOR 
(/:SUCCESSOR 

(/:SUCCESSOR 


(EXPLODER ?PI> (CORE-FINDER ?PI)> 
(EXPLODER ?PI> 

(SIOE-TASKS-FINDER ?PD) 

(EXPLODER ?PI> (FERTURES-FINOER ?PI)) 
(HRIN-TRSK-INFERER ?PI> (GATHERER ?PI>) 
(SIOE-TASKS-FINDER ?PI) 

(GATHERER ?PI)) 

(FERTURES-FINOER ?Pt) (GATHERER ?PI)) 


(/:HAIN (GATHERER ?PI) ?SUP)))J 
GENERAL-DP*) 


jTHE INTENT OF D-EXPLOOE IS TO DISCOVER O-SHRROS, UHICH GENERATE 
| (1) CORE-OEV-TYPE, THE KIND OF DEVICE UHICH HAS THE OESIREO PROPERTY 
I (2) D-FERTURES, UHICH UILL GUIDE (RS POLICIES) THE HRKER OF THE DEVICE 
1 (3) SIDE-TASKS, UHICH TYPICRLLY RRE CONSTRAINTS ON PROPERTIES OF THE 
l DEVICE 


(DEFHLR D-EXPLODE 

l/:TO-DO ?T (D-EXPLODE 7+PROP) <> 

</:INFER ’(D-SHHRO ?+PROP 7+PROP) <>))) 


(DEFHLR D-SHRRD 

!-/> fl (D-SHRRO ?+P IN <J>+V) (RND !#_?+CS>J> 

(FORRLL UC> (/sGEN (NOT (ELT 7+C ?*CS)> 

(O-SHARO ?+P l\ (_?+V) _?+CJ>> )J 

GENERAL-DP*) 


(DEFHLA ACCOUNT-FOR-ALL-DO 



Appendix 2 


206 


I/:TO-OO ’T (RCCOUNT-FOR-ALL-SHRRDS ’♦?> <> 

(/:PRIH *SETUP)I 
GENERRL-DP*) 

(DEFHLR RCCOUNT-FOR-RLL-FIRISH 

I-/> R (/:TflSK-RCTION ?FIN (/:FINISH (RCCOUNT-FOR-RLL ?PI))> 
(AND (/:REDUCED ?FIN) 

<-/> G (AND (/iPLRN-INSTRNCE ’PI 

(DESI-REPHRRSE-PLRN ?+P ’+TSK 
’+DEVNAHE 
’♦WRY) 

?SUP) 

(D-SHRRO ?+P ’+SHRRO)) 

(STRSK (SHRRD-flCCOUNTflNT ’+SHRRD) ?FIN 
<> 

(\ 0 

(RCCOUNT-FOR-SHRRD ’+SHRRD 
’♦P) > 

<»))))) 


(DEFHLR SHRRO-ACCOUNT-DO 

I/:TO-DO 7 TSK (RCCOUNT-FOR-SHRRD 7+SHRRD 7+P) <> 
</:Cflll (SHRRD-RCCOUNT-CHERT 7+SHRRO ?+P))l 
GENERAL-DP*) 

;THIS IS HANDLED BY R LISP FUNCTION (NOT SHOWN) 

I IN THE CURRENT IHPLEHENTRTION 


(DEFHLR 0-NOTE-DO 

t/i TO-DO 7TRSK (D-NOTE ’PROPERTY) <> (/:PRI(1 *SETUP)I) 

(DEFulr d-note-finish 

t/:TO-DO 7TRSK (/(FINISH 7PTRSK (O-NOTE ’PROPERTY)) <> 

</sPRIf1 *FIN1SHE0)I) 

(DEFHLR CQ-FUNS-1 I/iflNTEC (NOT (DERIVEO-CQ ’ (?F ?X))> 

(CONTROL-ATTRIBUTE ?F))> 

(OEFHLR CQ-FUNS-2 1/sRNTEC (NOT (IflflEDIfiTE-CQ ’ (?F ?X))) 

(CONTROL-ATTRIBUTE ’F>)> 

(OEFHLR CQ-SHARO 

I/:RNTEC (NOT (O-SHARO ’+P (\ (_?+V> (» _’+EXPl _’+EXP2)I>) 

(AND (POS-CQ-SHARD 7+P 7+V 7+EXP1 7+EXP2) 

(POS-CQ-SHARO ’+P 7+V 7+EXP2 7+EXP1)))) 

(DEFHLR POS-CQ-SHARO 

1/sRNTEC (NOT (POS-CQ-SHARD ’+P 7+V 7+EXP1 7+EXP2)) 

(/:GEN (NOT (AND (NOT (CONTAINS 7+EXP2 l(|??| _?+V>]>> 
<»/> ’(DEN t\ (_?+V) _?+EXPl]) 

?F) 
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(CONTROL-ATTRIBUTE ?F> 

(./> ’(DEN ?+F» ?F)>) 

(SIOE-TASK ?+P 
IN (_?+V) 

(CONSTRAIN <’(_?+F (|??| _?*V))> 

(\ (X) (. ?X _?+EXP2) )) l))l 

GENERAL-OP*) 

(DEFHLH CORE-DT-L 

I/iRNTEC (NOT (O-SHARO ?+P IN (_?+V) (DEV-TYPE (/?/? _?+V) 

_?+DT)J)) 

(CORE-DEV-TYPE ?+P ?+DT)J) 


jCHOOSING CORE-OEV-TYPES 
(DEFfILA CORE-DT-CHOOSE 

I/iANTEC (NOT (CHOICE ?C ANSWER ICORE-DEV-TYPE _?*+P _?++OJ)> 
<-/> G (ANO (/(OPTION ?C ?A1 

ICORE-DEV-TYPE _?+tP _?++Dll) 
(/(OPTION ?C ?A2 

ICORE-OEV-TYPE _?*+P _?++D2J) 
(SUB-OEV-TYPE (OEN (DEN ?++01>> 

(DEN (DEN 7++D2)))) 

(/(RULE-OUT ?A1))I) 

I PLUS OOnA IN-DEPENDENT INFO IN ZORCH 


(DEFfILA HAKE-BASIC 

t-/> A (BASIC-DEV-TYPE 7DEV-TYPE) 

(/(TO-DO ?TSK (HAKE ?OEV-TYPE> <?NAflE> 

(/(DO-SUBNET (flAKE-BASIC-NET ?OEV-TYPE) <DEVNAf1E>))J) 


(DEFfILA flAKE-BASIC-PLAN 

I-/> A (/(PLAN-INSTANCE ?PI (HAKE-BASIC-NET ?DEV-TYPE) ?SUP> 
(ANO (/-.TASK (GRABBER ?PI) <> 

(\ () 

(/(CALL 

(GRABBA (\ (X) 

(HAIN-DEV-TYPE ?X 

7DEV-TYPE) ))) ) 

<’(OEVNAHE ?PI)>) 

(/(HAIN (GRABBER ?PJ> ?SUP))J 

GENERAL-DP*) 

(DEFfILA HAKE-PRIH 

t-/> A (PRIHITIVE-OEV-TYPE ?OEV-TYPE) 

(-/> A (/(PLAN-INSTANCE 

?PI (flAKE-BASIC-NET ?OEV-TYPE) ?SUP) 

(FORALL (Q 0 C) 

(-/> G 

(FORALL (X) 



(IMPLIES (DEV-TYPE ’X ?OEV-TYPE> 

(CONTROL ?Q ?X ?0 70) ) 

(EXISTS (SUB) 

(STRSK ’SUB ’SUP <’(DEVNRHE ?P1)> 

(\ (X) (SELECT-VALUE 

’ (?q ?xn ) 

<>) >) )») 


(OEFflLR IIRKE-COMPOSITE 

{-/> R (COMPOSITE-OEV-TYPE ’DEV-TYPE) 

(-/> R (/:PLRN-INSTANCE 

?PI (MRKE-BASIC-NET ’DEV-TYPE) ’SUP) 
(EXISTS (SUB) 

(STRSK ’SUB ?SUP <’(DEVNRME ’PI)> 

(\ (X) (EXPAND ’X) ) 

<>) )))) 


(OEFflLR MRKE-IOERL 

[-/> R (IDERL-DEV-TYPE 7DEV-TYPE) 

(-/> R (/:PLRN-INSTRNCE 

?PI (MRKE-BRS1C-NET 7DEV-TYPE) ?SUP> 
(EXISTS (SUB) 

(STRSK ’SUB ’SUP <’(DEVNRME ’PI)> 

<\ (X) (IMPLEMENT ’X) ) 

<>) >>I> 


(OEFflLR COMPONENTS-NOTICE 
(-/> R (COMPONENTS 
(-/> G (ELT 
(-/> 


’X ’PARTS) 

’PART ’PRRTS) 

R (HRIN-DEV-TYPE ’X ?OT) 

(EXISTS (PI) 

(AND 1/iPLRN-INSTRNCE ’PI 

(HRKE-BRSIC-NET ’DT) 
(DEEP-FREEZE ’X)) 

(/:FINISHED (GRABBER ?PI>>> 


GENERAL-OP*) 


))>) 


{DEFINITION OF EXPANO 


I THE MOST GENERAL SPECIALIZATION ANO ANY DEFAULT SPECIALIZATIONS OF A 
I OEVICE TYPE ’G ARE TREATED THE SAME HERE, BUT (A) THE CHOICE RULES 
I BELOU HILL TAKE THE DEFAULT, OR (B) USER-SUPPLIED RULES MILL 
, FAVOR THE GENERAL. 


(DEFMLR MOST-GENERRL-OEFN 

(-/> A (MOST-GENERAL-SPEC ’G ’OT) 

(ANO (SPEC-DEV-TYPE ’DT ’G> 

(-/> C (MRIN-OEV-TYPE ?X ?G) 



</iTO-DO 7TASK (EXPAND ?X> <> 
(SPECIALIZE ?X ?OT) >>>I) 


(DEFflLA DEFAULT-SPEC-DEFN 


(-/> A (OEFAULT-SPEC ’C ?OT> 
(-/> C (flAIN-OEV-TYPE 
(/:TO-DO 7TASK 
(SPECIALIZE 


?X ?G) 

(EXPAND ?X) <> 
?X ?OT) ))]) 


(DEFflLA SPECIALIZE-OEFN 

l-/> C (flAIN-DEV-TYPE ?OEV 70L0-DEV-TYPE) 

(/sflOD-flANIP (SPECIALIZE 70EV 7DEV-TYPE) 

<’ (MAIN-DEV-TYPE 7DEV ?OLD-DEV-TYPE)> 
<’(AAIN-OEV-TYPE ?DEV ?DEV-TYPE)>)I) 

>IF ONE DEVICE-TYPE IS A SPECIALIZED VERSION OF ANOTHER, TRY 
j TO TAKE THE HORE SPECIFIC, OTHER THINGS EQUAL. 


(DEFflLA SPEC-DEV-BETTER 

l-/> A (OERIVEO ?OTl ?DT2) 

(-/> G (AND U/> > (DEN 7+DTL) 7DT1) 

(•/> ’(DEN ?+0T2) ?DT2>) 

(-/> A (/.-OPTION ?C ?R1 

(/:T0-00 _?+TSK (EXPANO _?+DEV) <> 
(SPECIALIZE _7+0EV _?+OTl))> 

(-/> A (/sQUIESCENCE 70 

(-/> G (/sOPTION 7C 7A2 

C/jTO-DO _7+TSK 

(EXPANO _?+DEV) 


GENERAL-DP*) 


<> 

(SPECIALIZE 


_?+DT _?+DT2)l) 
(/iRULE-IN ?A1)))))1 


(DEFflLA TUO-SPEC-DEVS-UORSE-THAN-ONE 
(-/> A (OERIVEO 70TI ?0T8) 

(-/> A (OERIVEO 70T2 ?DT0> 

(-/> G (AND (NOT (/:= 70TL ?DT2)) 

(=/> ’(DEN 7+OT0) 7DT0) 

(=/> ’(OEN nOTl) 7DT1) 

(=/> ’(DEN 7+DT2) ’DT2)) 

(-/> A (/sOPTION K ?A1 

t/sTO-OO _’+TSK (EXPANO _?+OEV> 

<> 

(SPECIALIZE J>+DEV _?+OTl)I> 

(-/> A (/tOUIESCENCE 70 

(-/> C (AND (/sOPTION ?C 7A2 

I/sTO-OO _?+TSK (EXPANO _?+DEV> 



(SPECIALIZE _?+DEV _’+0T2)D 
</:OPT ION ?C ?A0 
I/: TO-DO _’+TSK (EXPAND _’+DEV) 

<> 

(SPECIALIZE _?+DEV _’+DT0>D> 
(ANO (/sRULE-OUT ?A1> 

(/••RULE-OUT ?A2))>)>))D 

{AUXILIARY SUBTASKS OF EXPAND 
(DEFtlLA EXPAND-LOOKAHEAD 

[-/> A (/:TASK-ACTION ?TSK (EXPAND ?OEV)) 

(TO-BE-EXPANDED ’DEV ?TSK)I) 


(OEFfILA EXPANS ION-OBLS-OO 

1/jANTEC (NOT (EXPANSION-OBL ’DEV ’B>> 

(/:ANTEC (NOT (TO-BE-EXPANOED ’DEV ?TN)) 

(/iTASK (OBL ?OEV ?8) <» <\ () ?B) <>))]) 


(DEFHLA GENERIC-CAS 

I-/> A (GENERIC-CA ?CA) 

(ANO (CONTROL-ATTRIBUTE ?CA) 

(-/> A (/:POL ICY ’TASK 

(CONSTRAIN <!#?QSX ’(?CA ’DEV) l#’QS2> 
?P» 

(-/> G (ELT '(?CA ’X) 

<!#’QS1 M’CA ’OEV) !#’QS2>) 

(-/> A (TO-BE-EXPANDED ’DEV ’TSK) 

(STASK (CA-CALC ’CA ’DEV) ’TSK 
<> 

(\ () 

(CALCULATE 

’ (’CA ’DEV)) ) 
<>)))))! 

GENERAL-DP*> 

(DEFtlLA ACQUIRE-DO-1 

l-/> C (AND (REUSABLE ’DEV-TYPE) (DEV-TYPE ’X ’OEV-TYPE)) 

(/:TO-DO ’TSK (ACQUIRE ’OEV-TYPE) <’NAHE> 

(/:OUTPUT <’X>))1) 


(DEFtlLA ACQUIRE-DO-2 

t/iTO-DO ’TSK (ACQUIRE ’OEV-TYPE) <’NAt1E> 
(HAKE ’OEV-TYPE)]) 


(DEFtlLA REUSRBLE-1 (PRESUMABLY ’(NOT (REUSABLE ?X)) CD 
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(DEFflLR REUSE-CETERIS-PRRIBUS 

t-/> R </iCHOICE ?C EXEC I/iTO-DO _?+TASK IRCQUIRE _?+DT) <_?+N> 

_?+URYI) 

<-/> B </tQUIESCENCE K) 

(-/> fl (/(OPTION ?C 7R1 

t/(TO-DO _7fTRSK IRCQUIRE _?+DT> <_?+N> 
(HAKE _?+DT)l> 

(/:RULE-OUT ?R1)))1) 


i IF SIHPLE EQUATION, TRY SOLVING IT 
(DEFULR CONSTRRIN-OO-1 

t-/> C It. <7UNK> 

(/(THFIND 
(\ (U) 

(RNO (ELT ?U ’QUANTS) 

(/(CONSISTENTLY 
’ IFORRLL (VRL) 

(NOT (./> ?U 7VAD) ))) ))) 

(/(TO-DO 7TASK (CONSTRAIN 7QUANTS (CUP « <?Fi ?F2>)) <> 
(/iSEQ (CONSTRAINT-RESOLVE 7UNK ?F1 7F2 7QUANTS) 

(\ (VRL) 

(PROTECT 

’(SATISFIES 

7UNK (COP > <?FI ?F2>) ’QUANTS)> 

>>) 1 ) 


jELSE, JUST ESTABLISH POLICY 
(DEFflLR CONSTRRIN-DO-2 

t-/> C (OR (NOT (:. ?F = )> 

(FORALL (UNK) 

(NOT (:. <?UNK> 

(/iTHFINO 
(\ (U) 

(AND (ELT 7U 7QUANTS) 
(/(CONSISTENTLY 
’(FORALL (VRL) 

(NOT (./> ?U 7VRL)) 
)>) )))) )) 

(/(T0-00 ’TASK (CONSTRAIN 7QUANTS (CflP 7F 7P1)) <> 
(/:PRIt1 $SETUP))]) 


;DEFINITION OF "CONSTRAINT” — 

(OEFHLR CONSTRflINT-1 

t-/> R (CONSTRAINT 70S ’P> 

(EXISTS (T) (/(POLICY 7T (CONSTRAIN 70S TP.)) )I) 

(DEFflLR CONSTRAINT-2 

l-/> C (EXISTS (T) (/(POLICY ?T (CONSTRAIN 7QS 7P)) ) 

(CONSTRAINT 70S ?P)I) 



(DEFULR CONSTRAINT-RESOLVE-REPH 
l/jTO-DO 7RTSK 

(/:REPHRASE 7TASK 

(CONSTRAINT-RESOLVE _’+UNK 

<\ (_?+VARS> _?+EXPl) 

(\ (_?+VARS) _?+EXP2) 

<!#_?QUANTS>) 

<?VALUE>) 

(/:SEQ (EQN-SOLVE 7+UNK (LRfIBDR-APPLY (\ (_?+VARS> _?+EXPl) 

7+QUANTS) 

(LflfIBDfl-RPPLY <\ (_?+VARS) _?+EXP2) 
7+QUANTS)) 


(\ (+ANS) 

(/! INFER ' (ANO (STASK (SETTER 7TASK) 7TASK <> 

(\ () </iSET (DEN 7+UNK) 

(DEN 7+ANS)) ) 


<>) 

(/sflAIN (SETTER 7TASK) 7TASK) 
(/:REOUCEO 7TASK)) 

<>) ))]) 


(DEFULR EQN-SOLVE-OO-1 

(-/> C (AND (ONE-OCCURRENCE 7+LFT 7+UNK) 

(NOT (CONTAINS 7+RGT 7+UNK))) 

</!TO-DO 7TASK (EQN-SOLVE 7+UNKF 7+LFT 7+RCT) <?ANSV> 
(ISOLATE 7+UNK 7+LFT 7+RGT))]) 

(DEFULR EQN-SOLVE-DO-2 

(-/> C (RND (ONE-OCCURRENCE 7+RGT 7+UNK) 

(NOT (CONTAINS ’+LFT 7+UNK))) 

(/!TO-DO ’TASK (EQN-SOLVE 7+UNKF 7+LFT 7+RGT) <?ANSV> 
(ISOLATE 7+UNK 7 +RGT 7+LFT))]) 

(DEFfILfl EQN-SOLVE-00-3 

(-/> C (NOT (ONE-OCCURRENCE (_?+LFT _?+RCTJ 7+UNK)) 

(/!TO-DO 7TSK (EQN-SOLVE 7+UNK 7+LFT 7+RGT) <?RNS> • 
(/tCRLL (EQN-CHEAT 7+UNK 7+LFT 7+RGT))))) 

(THE TERN "ISOLATE" IS FROH BUNDY'S fl IN I—THEORY OF EQUATION SOLVING. 

I HIS NOTION OF "COLLECTION" IS ALSO APPROPRIATE, BUT NOT II1PLEHENTE0. 


(DEFfILfl ISOLATE-DO-1 

l/:CONSEQ (/:TO-DO 7TASK (ISOLATE 7+UNKF 7+LFT 7+REL 7+RGT) 
<?RV ?ANSV> 

(OUTPUT <?+REL ?+RGT>)) 

(NOT (= 7+LFT 7+UNKF))]) 


(DEFfILfl ISOLflTE-DO-2 



t/sCONSEQ (/sTO-DO 7TASK (ISOLATE 7+UNKF 7+LFT 7+REL 7+RGT) 

<?RV ?RNSV> 

</:SEQ (ISOLATE-ONE-STEP 7+UNKF 7+LFT 7+REL 7+RGT) 
<\ (+NEU-LFT +NEU-RGT) 

(ISOLATE 7+UNKF 7+NEU-LFT 

7+REL 7+MEU-RGT) ))) 

(■ 7+LFT 7+UNKF)J) 

(OEFMLB I SOL ATE-ONE-00-+ 

t/iCONSEQ (/sT0-00 ’TASK 

(ISOLATE-ONE-STEP 7+UNKF t+ !#_7+A00EN0SI 
7+REL 7+RGT) 

<?LV ?RV> 

(OUTPUT <?+TER(1 I- _?+RGT (+ !#_?+TERHS>) >)) 

(NOT (ANO (ELT 7+TERH 7+AOOENOS) 

(CONTAINS 7+TERH 7+UNKF) 

(« 7+TERMS (DEL 7+TERN 7+AOOENOS))))]) 


(OEFHLA SELECT-VALUE-DO 

t-/> C (/:CONSISTENTLY 

MFORALL (VOL) (NOT (=/> 7QUANT 7VAL)) )) 

(/:T0-00 ?T (SELECT-VALUE 7QUANT) <> 

(/iCALL (CHEAT 7QUANT (CQ-CLOSURE 7QURNT))))]) 
(SELECT-VALUE IS HANDLED BY 0 LISP FUNCTION 
(IN THE CURRENT IMPLEMENTATION 


(OEFMLA CQ-CLO-1 

t-/> ’ (CQ-CLOSURE ?Q) 

(/: THFINO (\ (C) (CQ-CLOSURE-ELT 7C ?Q) )>)) 

(DEFHLA CQ-CLO-2 

[-/> C (CONSTRAINT <!#?QTI 7Q !#?QT2> ?P> 

(CQ-CLOSURE-ELT (CONSTRAINT <!#?QT1 7Q 7QT2> ?P) 
?Q) 1) 


(OEFMLA CQ-CLO-3 

t-/> C (ANO (EQ-CLOSURE-ELT (CONSTRAINT 7QS ?P) 7Q) 

(ELT ?qi 7QS) 

(EQ-CLOSURE-ELT ?C 7Q1)) 

(CO-CLOSURE-ELT ?C ?Q)1) 

(OEFHLA SELECT-POSTPONE 

l-/> A (/:TASK ?TSK ?I (CMP DESIGN <’PF>) <?DEV>) 

(-/> A (/.-TASK ?S ’I (CMP SELECT-VALUE <?QF>) <>) 
(AND (STOSK (SELECT-EH-ALL 7TSK) 7TSK <> 

<N () (DO-ALL-SELECT-VALUES 7TSK) ) 
<>) 

(/:SUBTASK ?S (SELECT-EH-ALL ?TSK)> 
(/:REOUCED (SELECT-EH-ALL 7TSK)) 

(-/> A (TOPO-CHANGE-ACTION-FUN ?F) 
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(-/> A (/jTASK ?T ?JNS 

(CUP ?F ?FS) POUTS) 

(/:SUCCESSOR 

?T (SELECT-EH-ALL ?TSK))>)>)J 

GENERAL-DP*) 


(DEFflLR HAKE-CHANGES-TOPOLOGY 

ITOPO-CHANGE-ACTION-FUN flAKEl) 

(DEFflLR FIX-CHANGES-TOPOLOGY 

ITOPO-CHANGE-ACTION-FUN FIX)» 

(DEFfILA QVAL-PROTECT 

t-/> C (ANO (=/> ?Q ?VAL) 

(»/> MOEN ’+FACT) (./> ?Q ?VAU)) 

(/sTO-DO ’TASK (PROTECT ’(SATISFIES ?Q ?C ’QUANTS)) <> 
(/:HONITOR ’+FACT 
(\ (T) 

(/tCONTINUE ’TASK 
(PROTECT 

’(SATISFIES ?Q ?C ’QUANTS))) ))>J) 


(DEFflLR PROTECT-CONTINUE 

t/jTO-DO ’TASK (/:CONTINUE ’PTASK 

(PROTECT ’(SATISFIES ?Q ?C ’QUANTS))) 

<> 

(/:DO-SUBNET 

(PROTECT-CONTINUE-NET ’PTASK ?Q ?C ’QUANTS) <>))) 


(DEFflLR PROTECT-CONTINUE-PLAN 

(-/> A (/:PLAN-INSTANCE ’PI 

(PROTECT-CONTINUE-NET ’PTASK ?Q ?C ’QUANTS) 

?SUP> 

(ANO (STASK (RECHECKER ’PI) ’SUP <> 

(\ () (VERIFY ’(SATISFIES ?Q ’C ’QUANTS)) ) <>) 
(STASK (VALUE-FINDER ?PI> ’SUP <> 

(\ () 

(/:FINO 

(\ (+NEUHON) 

(EXISTS (NEUVAL) 

(ANO («/> ?Q ’NEUVAL) 

(«/> ’(DEN ’+NEUHON) 

(=/> ’Q ’NEUVAL))) ))) ) 

<’ (NEUflON ?PI)>) 

(STASK (REftONITOR ’PI) ’SUP <’(NEUflON ?PI)> 

(\ UFACT) 

(/sflONITOR ’+FACT 
(\ (T) 

(/tCONTINUE ’PTASK 
(PROTECT 



’(SATISFIES ?Q ?C 
7QUANTS))) 


M ))>)) 


(OEFfILR VERIFY-DO 

t/iTO-DO 7TSK (VERIFY ’?P) <> 

(/sFIND (\ () ?P) >)) 

(DEFHLA SPEC-SCHEMR-DEFN 

l-/> n (SPEC-SCHEMA ’SCH1 ?SCH2) 

(-/> A (/:PLAN-INSTANCE ?PI 7SCHI 7SUP) 

(/iPLAN-INSTANCE 7PI 7SCH2 7SUPDJ) 

I THIS PREOICRTE IS USEFUL IN RELATING R SCHEMA TO ITS SPECIRLIZERS 

(OEFfILfl REOUCE-OEFN 

l-/> fl (REDUCE 7TRSKS ’TASK) 

(RND (-/> G (ELT 7T 7TASKS) (/■SUBTASK ?T 7TASK)) 
(/:REDUCED 7TASK)))) 


(THIS IS R USEFUL PREDICATE ON FROZEN TASKS 
(DEFfILR FUNCTION-DEFN 

t-/> R (FUNCTION 7DEV 7TSK) 

(-/> R (MflIN-DEV-TYPE ?0EV 7DT) 

(EXISTS (RCQ) 

(AND (/:TASK 7RCQ 71 ?fl <?OEV>) 

(/:TASK-ACTION 7ACQ (ACQUIRE 70T)» 
(/:REOUCED 7RCQ) 

(REDUCE <?RCQ» ?TSK») ))J) 


jlP ONE PLAN-SCHEMA IS fl SPECIALIZED VERSION OF ANOTHER, TRY 
| TO TAKE THE MORE SPECIFIC. (THIS IS REALLY HORE GENERAL THAN 
; THE UORLO OF DESIGN.) 

(DEFMLA SPEC-IS-BETTER 

t-/> A (SPEC-SCHEMA 7SCH1 7SCH2) 

(-/> G (AND (=/> ’(DEN 7+SCH1) 7SCH1) 

(*/> ’(DEN 7+SCH2) 7SCH2)) 

(-/> fl (/tOPTION ?C ?A1 

(/!TO-DO _?4-TSK _?+ACT _?+OUTS 

(/:DO-SUBNET _?+SCHl _7+VflRSI)I) 
(-/> A </jOPTION ?C 7A2 

[/:TO-DO _?+TSK _?+ACT _7+OUTS 
(/:00-SUBNET _?+SCH2 

_?+VARS2>I) 

</jRULE—IN 7A1))))I) 


(OEFfILA TUO-SPECS-UORSE-THAN-ONE 

[-/> A (SPEC-SCHEMA 7SCH1 7SCH0) 

<-/» A (SPEC-SCHEMA 7SCH2 7SCH0) 

(-/> G (ANO (NOT (/i» 7SCH1 7SCH2I) 
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(»/> ’(DEN 7+SCH8) ?SCH8) 

(./> MOEN 7+SCH1) ?SCH1) 

(./> ’(DEN ?+SCH2) ?SCH2)> 

(-/> A 

C/sOPTION ?C ?R1 

C/sTO-DO _?+T$K _?+RCT _?+OUTS 
(/'.DO-SUBNET _?+SCHl J’+VRRSDI) 
(-/> C (UNO (/:OPTION ?C ?B2 

t/iTO-DO _?+TSK _?+RCT 
_?+OUTS 

< /1DO-SUBNET J>+SCH2 
_?+VRRS2)l) 
(/:OPTION ?C ?B0 
I/:TO-DO _?+TSK _?+ACT 
_?+OUTS 

</:DO-SUBNET _?+SCH8 
_?+VRRS0)I)) 
(AND (/:RULE-OUT ?fll) 

(/:RULE-OUT ?R2)>))))!) 


Appendix 3 -- A Listing of ZORCH 

This is the current version of DESI’9 electronics knowledge. Much of it 
interacts with the more general rules of the previous appendix. 


(INTSECT-OISPBRITY* 1088) 

(RLLOC MUST (180888. 158888. 0.6))) 

(PHYSICAL KNOULEOGE 

(EVERY NODE IS fl TERHINRL 

(DEFRLA NODE-TRHIN 

IFORALL (X) (-/> fl (DEV-TYPE ?X NOOE) (DEV-TYPE ?X TERIIINflL))I) 

(KCL FOR DEVICES 
(OEFHLfl KCL-1 

t-/> fl (TERHINflL-NRflES ?X ?TRf1 IN—TUP) 

(CONSTRAINT (flRPCAR (LAtlBOA (T) MI (?T ?X>> ) 

?TRf1 IN-TUP) 

(NFUN (LENGTH ?TRHIN-TUP> 

(LRNBDfl (L) (. (♦ !#?L) 8))))I) 


(KCL FOR NODES 
(DEFfILfl KCL-2 

I-/> fl U/> ’ (NOOE—TERM INRLS ?N0DE) 2TRHIN-TUP) 
(CONSTRAINT <’(I ’NODE) 

IftflRPCBR (\ (T) MI ?T) ) 



?TRHIN-TUP)> 

(NFUN <♦ (LENGTH ’TRHIN-TUP) 1) 

(LAHBDA <L) (m (♦ !#?U 0)))))) 

( ...AND COHPOSITE DEVICES 
(OEFHLfl 1CCL-3 

t-/> fl (COHPOSITE-DEV-TYPE ’OT) 

(-/> H (OEV-TERHINRLS ’DEV HRHIN-TUP) 

(CONSTRRINT (HRPCRR (\ (T) ’(I ?T> ) 

’TRHIN-TUP) 

(NFUN (LENGTH 7TRHIN-TUP) 

(LRHBOR (L) (« (+ !#’L) 0) 
>))>!> 


jKVL FOR NOOES 
(DEFHLfl KVL-1 

t-/> fl («/> ’ (NOOE-TERHINRLS ’NODE) ’TRHIN-TUP) 

<-/> G (ELT ’TRHIN ’TRHIN-TUP) 

(CONSTRAINT <’(V ?TRHIN) ’(V ?NOOE)> «))1) 


iSOHE TERHINRLS HAVE NODES THAT THEY RRE TERHINRLS OF 

(DEFHLfl NODE-OF-1 (-/> fl <=/> • (NODE-TERHINRLS ’N) ?TS> 

(-/> G (ELT ’T ?TS> (NOOE-OF ?T ?N))J) 

(OEFHLfl NODE-OF-2 (PRESUHRBLY ’(NOT (NOOE-OF ’T ’N)) Cl) 


(NODES CAN BE HERGED 
(DEFHLfl NODES-HERGE-HRNIP 

(-/> C (AND (*/> ’(NOOE-TERHINRLS ?N1) ?T1) 

(«/> ’(NODE-TERHINRLS ’N2) ?T2)) 

</:MOO-HRNIP ?TRSK (NOOES-HERGE ’Nl ?N2) 

<’(=/> ’(NODE—TERM INOLS ?N1) ?T1) 

’(»/> ’(NODE-TERHINRLS ’N2) ’T2)> 

<’(=/> ’(NOOE-TERHINRLS ’NI) (UNION ?T1 ?T2)) 
’ (=/> ’?N2 ’N1)»)J) 


(TERHINRLS CRN BE CONNECTED TO CREATE NEU NODES OR HERGE OLD ONES 

(DEFHLfl TRHINS-CONNECT-DO-1 

t-/> C (AND (NOOE-OF ’T1 ’Nl) (NOOE-OF ’T2 ?N2)) 

(/!TO-DO ’TASK (TRHINS-CONNECT ’T1 ?T2) <> 
(NOOES-HERGE ’Nl ’N2))J) 

(DEFHLfl TRHINS-CONNEC T-DO-2 

(-/> C (AND (NOOE-OF ’T1 ’Nl) 

(CONSISTENTLY 

’(FORRLL (N) (NOT (NODE-OF ’T2 ?N>> )) 

(»/> ’ (NODE-TERHINALS ?N1) ’TSD) 



I/sOOD-OANIP ’TASK (TRUINS-CONNECT ?T1 ?T2) 

<’(*/> '(NODE-TEROINRLS ?H1) ?TS1)> 

<’(=/> ’(NODE-TEROINRLS ?N1) <?T2 !#?TS1>)>)J) 

(DEFOLA TROINS-CONNECT-DO-3 

l-/> C (AND (NODE-OF ’T2 ’N2> 

(CONSISTENTLY 

MFORRU <N) (NOT (NOOE-OF ?T1 ?N>) )) 

(*/> ’(NODE—TERM INRLS ’N2) ?TS2>) 

(/:000-OANIP ’TASK (TROINS-CONNECT ?T1 ?T2) 

<’U/> ’(NOOE-TEROINRLS ’N2> ?TS2)> 

<’(*/> ’(NOOE-TERNINRLS ?N2» <?T1 !f?TS2>)>)I) 

(DEFOLA TROINS-CONNECT-DO-* 

{-/> C (AND (CONSISTENTLY 

’(FORRLL (N> (NOT (NOOE-OF ?T1 ’N)> )> 

(CONSISTENTLY 

’(FORRLL (N) (NOT (NOOE-OF ?T2 ?N)> ))) 

</j MOO—URN IP ’TASK (TROINS-CONNECT ’T1 ?T2) 

<> 

<’(EXISTS (N) 

(=/> ’(NOOE-TEROINALS ’N> <?T1 ?T2») )>)J) 


I INSERTING fl DEVICE INTO A NODE BREAKS IT INTO TUO NOOES 
(OEFMLR OEV-INSERT 

l-/> C (AND (=/> ’(NODE-TEROINRLS ’NODE) ?TS> 

(* (SET ?TS1) (SET <!#’TSi !#?TS2>)»> 
(/sflOO-ORNlP ’TASK 

t (DEV-INSERT ?D ’NOOE ?T1 ?TSI ?T2 ?TS2) 
<’(=/> ’(NODE-TEROINRLS ?NOOE> ’TS)> 

<’(=/> ’(NODE-TEROINRLS ’NODE) <?T1 !#’TS1») 
’(EXISTS (NEUNOOE) 

(RND (DEV-TYPE ’NEUNOOE NOOE) 

(./> ’(NODE-TEROINRLS ’NEUNOOE) 
<’T2 !#’TS2>>) )>)]> 

(DEFULR PORT-DEFN (PRIOITIVE-OEV-TYPE PORT!) 

I PORTS CARRY VOLTAGE OR CURRENT 

(DEFULR PORT-TRXONOOY IXOR1 (DEV-TYPE ’X PORT) 

<(V-PORT ’X) (I-PORT ?X)>) 
GENERAL-DP#) 


(DEFOLA PORT-OEDIUO-l 

t-/> C (V-PORT ’X) ( = /> ’ (PORT-OEOIUO ’X) VOLTAGE)!) 
(DEFOLfl PORT-OEDIUO-2 

t-/> C (I-PORT ’X) U/> ’(PORT-OEOIUO ’X) CURRENT))) 
jOOST PORTS ARE VOLTAGE PORTS 

(DEFOLA PRES-V-PORT (-/> C (AND (DEV-TYPE ’X PORT) 

(CONSISTENTLY ’(V-PORT ?X>>> 
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(V-PORT ?X)]> 


jR NEST IS MRDE UP OF PORTS RND IS ITSELF R PORT 

(DEFMLR NEST-PORT I-/> R (OEV-TYPE ?X NEST) (OEV-TYPE ?X PORT)!) 

(OEFHLR NEST-OF-1 l-/> R («/> ' (NEST-PORTS ?N) 7TS) 

(-/> G CELT ?T ?TS) (NEST-OF ?T ?N))J) 

(DEFfILfl NEST-OF-2 (PRESUMABLY ’(NOT (NEST-OF ?T ?N)) C!) 

jPORTS ARE HOMES FOR SIGNALS 

(KVl FOR PORTS 
(DEFHLR KVL-2 

t-/> fl <«/> ’(NEST-PORTS 7NEST) 7PORT-TUP) 

<-/> G (ELT ’PORT 7PORT-TUP) 

(RND (-/> R (SIGNAL-HOME ?SIG ?PORT) 

(SIGNAL-HOME 7S1C ?NEST))))I) 

(OEFHLR SIGNAL-HOME 

C-/> R (SIGNAL-HOME 7SIG ’PORT) 

(-/> ’(PORT-SIGNAL 7PORT) 7SIG)]) 

}THESE ACTIONS ARE ANALOGOUS TO THE NODE ACTIONS 

(OEFHLR NESTS-MERGE-MANIP 

t-/> C (RNO (=/> ’(NEST-PORTS ’Nl) 7T1) 

<•/> ’(NEST-PORTS ?N2> ?T2)> 

(/:MOD-MAN IP 7TASK (NESTS-MERGE 7N1 7N2) 

<’(»/> ’(NEST-PORTS 7N1) 7T1) 

’(=/> ’(NEST-PORTS ’N2) ?T2)> 

<’(*/> ’(NEST-PORTS 7N1) (UNION 7T1 7T2)» 

’(=/> ’ 7N2 ?N1)>) J) 


(dEFMLR PORTS-CONNECT-OO-1 

I-/> C (ANO (NEST-OF ?T1 ’Nl) (NEST-OF 7T2 7N2)) 

</:TO-DO 7TASK (PORTS-CONNECT 7TI 7T2 7TYPE) <> 
(NESTS-MERGE ’Nl ’N2))l) 

(DEFMLR PORTS-CONNECT-OO-2 

(-/> C (AND (NEST-OF ’T1 ’Nl) 

(CONSISTENTLY 

’ (FORRLL (N) (NOT (NEST-OF 7T2 ?N)) )) 

(r/> ’(NEST-PORTS 7N1) 7TS1)) 

(/jHOD-MANIP 7TRSK (PORTS-CONNECT 7T1 7T2 7TYPE) 
<’(=/> ’(NEST-PORTS 7N1) ?TS1)> 

<’(=/> ’(NEST-PORTS 7N1) <?T2 !#?TS1>)>)1) 

(DEFMLR P0RTS-C0NNECT-D0-3 

t-/> C (RND (NEST-OF 7T2 7N2) 



(CONSISTENTLY 

’(FORALL (N) (NOT (NEST-OF ?T1 ?N)) )) 

(=/> ’(NEST-PORTS ?N2) ?TS2)> 

(/sMOD-MANIP 7TASK (PORTS-CONNECT ?T1 ?T2 7TYPE) 

<’(=/> ’(NEST-PORTS ?N2) ?TS2)> 

<* < = /> ’(NEST-PORTS ?N2) <?T1 !#7TS2>)>)J) 

(DEFMLA PORTS-CONNECT-DO-4 

C-/> C (AND (CONSISTENTLY 

’(FORflLL (N) (NOT (NEST-OF 7T1 ?N>) )) 

(CONSISTENTLY 

’(FORflLL (N) (NOT (NEST-OF ?T2 ?N)) ))) 

</:HOD-MANIP ’TASK (PORTS-CONNECT ?T1 7T2 7TYPE) 

<> 

<’(EXISTS (N) U/> ’(NEST-PORTS ?N) <?T1 7T2>) )>)]) 


(DEFMLA PORTS-CONNECT-DIRECT-DO 

[-/> C (flNO (PORT-TERMINALS 7PRT1 <?TOPl ?B0T2>) 

(PORT-TERMINALS ’PRT2 <?TOP2 ?BOT2>) 

(OR (/iMOO-MANIP ’TASK (TRMINS-CONNECT 7TOP1 7TOP2) 
?DEL ’ADO) 

(/:NOD-MRNIP ’TASK (TRMINS-CONNECT 7BOTL 7B0T2) 
’DEL ’ADO))) 

(/:MOD-MANIP ’TASK (PORTS-CONNECT 7PRT1 ’PRT2 DIRECT) 
’DEL ’ROD)I) 


(DEFftLA PORTS-CONNECT-CAPRCITIVE-00 

t-/> C (AND (PORT-TERMINALS ’PRTL <’TOPl ’BOTl>) 
(PORT-TERMINALS 7PRT2 <?T0P2 ?BOT2>)) 

(/:TO-DO ’TSK (PORTS-CONNECT 7PRT1 7PRT2 CAPACITIVE) <> 
(CONFIG <CAPACITOR> 

(\ (C) 

<(TRMINS-CONNECT (#1 ’C) ’TOPI) 

(TRMINS-CONNECT (#2 ’C> 7TOP2)> )))J) 


(DEFMLA PORTS-CONNECT-INDUCT IVE-00 

l-/> C (AND (PORT-TERMINALS ’PRT1 <?T0P1 7BOTl>) 
(PORT-TERMINALS ’PRT2 <?TOP2 ?B0T2>>) 

(/:TO-DO ’TSK (PORTS-CONNECT 7PRT1 7PRT2 INDUCTIVE) <> 
(CONFIG <TRANSFORMER> 

(\ (LL) 

<(TRMINS-CONNECT (#2 7LL) 7TOP1) 
(TRMINS-CONNECT (#4 7LL) ?TOP2»> ))))) 


(SIGNALS 

(DEFMLA FL-SHAPE (ELT (FL-SHAPE 7LM) <HUMP SPIKE>J) 


(DEFMIA FF-FREQ t«/> ’ (FF-FREQ (FF ?F ?LM)> 7FJ) 



(DEFNLR FF-LRNONRRK U/> ’ (FF-LANDHARK (FF ?F ?LH)) ?LNJ) 


(OEFNLA PERtODIC-FREQ-PIC 

t-/> C (PERIODIC ?S ?T> 

(«/> ’ (FREQ-PICTURE ’S) 

(imiON (POSSIBLE-DC-SUB-PIC ?S) 
(SERIES-SUB-PIC ?S)))J) 


(DEFNLR DC-FEATURE-1 

l-/> C (UNO (PERIOOIC 7TFUN ?T) 

(» (OFFSET 7TFUN) ?V) 

(/> (BBS ?V> an 
(-/» ’(POSSIBLE-OC-SUB-PIC ?S) 

< (FF 6 (DC-LANDHARK 7TFUN ?V))>)J) 


(OEFfILB DC-FEATURE-2 

I-/> C (AND (PERIOOIC 7TFUN ?T) 

(= (OFFSET 7TFUN) 8)) 

(•/> ’(POSSIBLE-DC-SUB-PIC ?S) <>>J) 

(DEFNLR DC-LANDHARK-1 

t»/> ’ (FL-SHRPE (DC-LRNDMARK 7TFUN ?VI) SPIKE] 
GENERAL-OP*) 

(OEFHLA OC-LANDNARK-2 

t=/> ’ (FL-HEIGHT (DC-LANDfIRRK ?TFUN ?V>> ?VI 
GENERAL-OP*) 


(OEFHLR FREQ-PIC-ELTS IMPLIES (ELT ?X (FREQ-PIC ?S)) 

(IS FREQ-FERTURE ?X)J) 


(DEFNLR SPIKES 

t-/> A (PERIODIC ?TFUN ?T) 

(FORALL (X) (-/> C (ELT ?X (FREQ-PICTURE 7TFUN)) 
(• (FL-SHAPE ?X> SPIKE)) )1 


(OEFNLA SINUSOIORL-SPIKE 

I-/> C (AND (PERIOOIC >TFUN ?T) 

(SINUSOIDAL ’TFUN) 

(RMPLITUOE ?TFUN ?fl)> 

(•/> ’(SERIES-SUB-PIC 7TFUN) 

<(FF 8 (SIN-LANDMARK 7TFUN ?T ?A))>)J) 


(OEFNLA EVERYOTHER-SERIES 

(-/> C (ANO (PERIOOIC 7TFUN ?T) 

(NOT (SINUSOIDAL 7TFUN)) 

(FORALL (X) 

(* (7TFUN ?X) (7TFUN (♦ ?X (// ?T 2)))) 
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(«/> ’(SERIES-SUB-PIC ?TFUN) 

(SERIES (* 2 PI <// 1 ?T)) <* * PI <// 1 ?T)) 
SPIKE 
(\ (M) 

<INTEGRAL 8 ?T 
(\ (U) 

(* (7TFUN ?U) 

(COS (# 2 PI (- (* 2 ?H) 1) 
?U U/ 1 ?T))>) )) 

))]) 


) 


(DEFfILA STRAIGHT-SERIES 

[-/> C (AND (PERIOOIC 7TFUN ?T> 

(NOT (SINUSOIOAL 7TFUND 
(EXISTS (X) 

(NOT (« (?TFUN 7X> 

(?TFUN (+ ?X (// ?T 2>>>>) )> 


(-/> ’(SERIES-SUB-PIC ’TFUN) 

(SERIES (* 2 PI (// 1 ?T>) (* 2 PI <// 1 7TD 
SPIKE 
(\ (N) 

(INTEGRAL 8 ?T 
(\ (U> 

<* (7TFUN ?U) 

(COS (# 2 PI 7N 

?U (// 1 ?T))>) )) 


>>D 


) 


(DEFHLA SIN-LANDHARK-SHAPE 

C-/> ’ (FL-SHAPE (SIN-LANOMARK 7TFUN ?T ?A)> SPIKED 

(DEFfILA SIN-LANDMARK-HEIGHT 

t«/> ’ (FL-HEIGHT (SIN-LANDMRRK 7TFUN ?T 7AD ?RD 


(DEFfILA SINU+ l-/> C (ANO (ELT 7SIN 7FS) 

(SINUSOIDAL 7SIN) 

(FORALL (F) 

(EXISTS (A) 

(IMPLIES (ELT ?F (DEL 7SIN 7FS)) 
(/!= ?F <K 1 7AD) )D 
(SINUSOIDAL (CHP + 7FSDD 

(DEFfILA SINU* (-/> C (ANO (ELT 7SIN ’FS> 

(SINUSOIDAL ’SIN) 

(FORALL (F) 

(EXISTS (A) 

(IMPLIES (ELT ?F (DEL 7SIN 7FS)) 
(/!. ?F (K I ?A))) D) 
(SINUSOIDAL (CMP * 7FSDD 


(DEFfILA SIN-SIN t-/> C (LINEAR 7F) 



(SINUSOIDAL (COP SIN <?F>))1) 


(DEFHLA COS-SIN {-/> C (LINEAR ?F) 

(SINUSOIDAL (COP COS <?F>))I) 

(DEFMLA LIN1 (LINEAR (ION ?N ?»C»I» 

(OEFMLA LIN2 {-/> C (AND (ELT ?LIN ?FS> (LINEAR ?LIN> 

(FORALL (F> 

(EXISTS (A) 

(IMPLIES (ELT ?F (DEL ?LIN ?FS)> 
</!. ?F (F l ?A)>) ))) 

(LINEAR (CUP * ?FS))1) 

(DEFMLA LIN3 (-/> C (FORALL (F) (IMPLIES (ELT ?F ?FS) (LINEAR ?FM 
(LINEAR (CMP + ?FS)) 1) 

(OEFMLA LIN* (-/> C (LINEAR (CMP + <?F1 (\ (X) (- (?F2 ?X)> )>)) 

(LINEAR (CMP - <?F1 ?F2>»>1 > 

(OEFMLA LIN5 (-/> C (AND (LINEAR ?F1> 

(/!* ?F2 (F 1 ?A>>) 

(LINEAR (CMP // <?F1 ?F2>)>|> 

(OEFMLA SIN-PERIODIC (PERIODIC SIN (* 2 PI))) 

(OEFMLA COS-PERIODIC (PERIODIC COS (* 2 PDI) 


(DEFMLA PRES-NOT-SIN (PRESUMABLY ’(NOT (SINUSOIOAL ?F)> Cl) 


(OEFMLA OFFSET-DEFN (-/> A (PERIODIC ?TFUN ?T) 

(•/» ’(OFFSET ?TFUN) 

(// (INTEGRAL B ?T ?TFUN) ?T))J> 


(LINEAR-DERIVED HOOELS 

1 (ISOLATE T1 T2) IS A UORLO IN UHICH THE CIRCUIT IS DECOUPLED 

(DEFMLA REF-ISO (IS REF (ISOLATE 7TRMIN1 7TRMIN2))) 

(OEFMLA FRAME-ISO ((FRAME (ISO ?TRMIN1 2TRMIN2) <(HERE)>)1) 

(OEFMLA ISOLATE-DEFN-1 

t-/> C (AND (»/> ’ (NOOE-TERMINALS ?N1) 

•c!#?TS11 ’TRMIN1 !#?TS12>) 

(»/> ’(NODE-TERMINALS ?N2) 

<!#’TS21 TTRMIN2 !#?TS22>)> 

(T (ISOLATE 2TRMIN1 ?TRM!N2) 

(AND (-/> ’(NOOE-TERMINALS ?N1> 

<!#?TS11 !#?TS12>) 

(./> ’(NODE-TERMINALS ?N2) 

<t#?TS2I !#?TS22>))))) 



(DEFHLR ISOLATE-OEFN-2 

t-/> C (./> ’ (NOOE-TERMINALS ?N1) 

<!#?TS11 7TRHIN1 i#?TS12>) 

(N (ISOLATE 7TRHIN1 7TRHIN2) 

’(./> ’(NODE-TERMINALS ?N1> 

<!#?TS11 nROINI !#?TS12>)))) 


(DEFHLR ISOLATE-DEFN-3 

t-/> C («/> ’ (NODE-TERHINALS 7N2) 

<!#?TS21 7TRHIN2 !#?TS22>) 

(N (ISOLATE 7TRHIN1 7TRHIN2) 

’(./> * (NOOE-TERttINALS 7N2) 

<!#7TS21 7TRH1N2 !#?TS22>>>1> 


jFOR THE FOLLOMING REFERENCE-POINT DEFINITIONS, 

I SEE CIRCUIT PACKETS FOR ALTEREO COHPONENT PROPERTIES IN EACH REF 

(DEFHLR REF-DC (IS REF (DC)I) 

(DEFHLR FRAHE-OC I (FRRHE (DC) <(HERE)>)1) 


(DEFHLR REF-SSS (IS REF (SSS 7FREQ)I) 

(DEFHLR FRAflE-SSS WFRAHE (SSS ?S) <(HERE)>)J) 


(DEFHLR REF-INC IIS REF (INC))) 

(DEFHLR FRRHE-INC KFRRHE (INC) <(HERE)>)D 


(DEFHLR REF-PRSSIVE IIS REF (PASSIVE))) 

(DEFHLR FRRHE-PASSIVE ((FRAHE (PASSIVE) <(HERE)>))) 

jINTERACTIONS — 

jTHIS HERNS (T (DC) (DC)) * (DC) 

(DEFHLR OC-IOEH [REF-IDEHPOTENT (DC))) 

(DEFHLR ISOLATE-IDEH [REF-IOEHPOTENT (ISOLATE 7TRHIN1 7TRHIN2))) 
(DEFHLR - SSS-IDEH (REF-IOEHPOTENT (SSS ’S>)) 

(DEFHLR PRSSIVE-IOEH (REF-IOEHPOTENT (PASSIVE))) 

(DEFHLR INC-IDEH IREF-IDEHPOTENT (INC))) 

(DEFHLR DC-ISO {./> ’(T (DC) (ISOLATE 7TRHIN1 7TRHIN2)) 

(T (ISOLATE ’TRH1N1 7TRHIN2) (00)1) 



(OEFMLA PASSIVE-DC (»/> ’ (T (PASSIVE) (OO) <T (DC) (PASSIVE)))) 


IINFORMATION ABOUT REPHRASING ELECTRONIC OESIGN PROBLEHS 

jD-SHARDS ARE FRAGMENTS OF OESIGN PROPERTIES) THOSE DEALING MITH 
) CONTROL QUANTITIES ARE IMPORTANT 

I THESE APPLY TO "10" DEVICES 

(OEFMLA CQ-V-GAIN IGENERIC-CA V-GAIN1) 

(OEFMLA CO-P-GAIN IGENERIC-CA P-GAIN1) 

(DEFMLA CQ-IZ IGENERIC-CA INPUT-ZI) 

(OEFMLA CQ-OZ IGENERIC-CA 0UTPUT-Z1 > 


(OEFMLA V-GAIN-SHRRD 

l-/> A (D-SHARD ?+P t\ (_? + V) (. (V-GAIN <|??| _?+V)) 

_?♦ G>)) 

(ANO (SIDE-TASK ?+P 

IN (_?+V> 

(CONSTRAIN <’(V-GAIN (|??| _?+V))> 

(\ (Gl> (• ?Gl _?+G) )))) 

(-/> G (. (DEN T+G) ?G) 

(ANO (-/> G (/» ?G 1008) 

(D-FEATURE ?+P 

(RANGER V-CAIN VERY-HIGH))) 
(-/> G (ANO (/> ?c 50) 

(/< ?G 5000)) 

(O-FEATURE ?+P 

(RANGER V-GAIN HIGH))) 

(-/> G (AND (/> ?G 1) 

(/< ?G 100)) 

(P-FEATURE ?+P 

IRANGER V-CAIN MODERATE))) 
(-/> G (*/< ?C l) 

(O-FEATURE ?+P 

IRANGER V-GAIN LOU)))))))) 


I "GAIN" ALONE MEANS V-GAIN ANO P-GAIN 
(OEFMLA GAIN-SHARD 

t-/> A (O-SHARO ?+P IN (_UV> (. (GRIN (|??| _?+V)) 

_?+G)l) 

(ANO (O-SHARO ?+P IN (_?+V) (« (V-GAIN (|??| _?+V)> 

_?+G))> 

<-/> G (ANO (. (* 20 (LOG (DEN _?+G)>) ?PG) 

;CONVERT TO OECIBELS 
U (DEN ?+PG) ?PG)) 

(O-SHARO ?+P 
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l\ <_?+V» (. (P-GAIN (|??| _? + V)) 
_?+PG)J)))J) 


(OEFIILfl INPUT-Z-SHHRD 

t-/> fl (D-SHRRD ?+P t\ (_?+V> (» (INPUT-Z (|??| _?+V)> 

_?+Z»l> 

(-/> G (» (DEN 7+Z) W 

(RND (-/> G (/» ?Z 3.8E5) 

(O-FERTURE ?+P 

IRRNGER INPUT-2 VERY-HIGH!)) 
<-/> G (RND </> ?Z 1.5E3) 

(/< ?Z 5.0E5)) 

(O-FERTURE ?+P 

IRRNGER INPUT-2 HIGH!)) 

(-/> G (AND (/> ?Z 568) 

(/< ?Z 2.8E3)) 

(O-FERTURE ?4P 

IRRNGER INPUT-Z HODERHTE)>) 
(-/> G (/< ?Z 1888) 

(D-FERTURE ?+P 

IRRNGER INPUT-Z LOW))))!) 


(DEFm.fi OUTPUT-Z-SHRRD 

t-/> R (D-SHRRD ?+P t\ (_’+V) (. (OUTPUT-Z (|??| _?+V)) 

_?*Z)I) 

(-/> G I* (DEN ?+Z) ’Z) 

(RND (-/> G (/> ?Z 1.0E6) 

(D-FERTURE ?+P 

IRRNGER OUTPUT-Z VERY-HIGH))) 
<-/> G (AND (/> ?Z 1.0E5) 

(/< 1.5E6)) 

(D-FERTURE ?+P 

IRRNGER OUTPUT-Z HIGH))) 

(-/> G (RNO (/> ?Z 1.0E4) 

(/< ’Z 1.5ES)) 

(O-FERTURE ?+P 

IRRNGER OUTPUT-Z HOOERRTE1)) 

(-/> G (RND (/> ?Z 100) 

(/< ?Z 1.5E4)) 

(O-FERTURE ?+P 

IRRNGER OUTPUT-Z LOUD) 

(-/> G (/< ?Z 208) 

(O-FERTURE ?+P 

IRRNGER OUTPUT-Z VERY-LOW)))))) 

(SOURCE! URTSON (1978), P. 66 


(SHRRDS REGARDING SIGNAL CONVERSIONS RUST BE EXPLODED SPECIALLY 

(DEFfILfl CONVERT-EXPLOOE 

t-/> R (/:TRSK-RCTION ?T (D-EXPLOOE ?+P)) 



(-/> A 


(D-SHARD ’+P 
l\ (_?+V) 

(CONVERT (|??| J>+V> _?+Q _?*RJ1) 
(EXISTS (Tl) 

(AND (STASK ?T1 ?T <> 

(\ 0 (CVT-EXPLOOE ?+Q ?+R) > 

<>) 


GENERAL-OP*> 


(/iMAIN ?T1 ?T) 

(-/> A (SIG-FEATURE ?+0 ?+R ?♦FEATURE) 
(O-SHARO ?*P 
(\ <_?+V> 

(SIG-TRANS _?+V 

_?+FEATURE)l))) ))) 


jTHERE ARE TUO HAYS TO DO THIS— 


(OEFMLA CVT-EXPLODE-1 

t/i TO-DO ’TASK (CVT-EXPLOOE ?+R) <> 

(FREQ-DOHAIN-REPHRASE ?+Q ’+R)J) 

(OEFMLA CVT-EXPLODE-2 

t/sTO-DO ?TASK (CVT-EXPLODE ’+0 ?+R» <> 

(tihe-oomrin-rephrase no ?+r>j> 

I BASIS ON WHICH TO CHOOSE ONE OR THE OTHER 
(OEFMLA CVT-CHOICE 

t/iANTEC (NOT (/sCHOICE ?C EXEC 
l/:TO-OO J’+TRSK 

(CVT-EXPLOOE _?++Q _?++R) <> 

_?++METHOOJ)> 

(-/> A (/!OPTION K ’A1 

I/:TO-DO _?+TASK 

(CVT-EXPLOOE _?+♦(! _?++R) 

<> 

(FREQ-OOMAIN-REPHRRSE 
_?++Q _?++R)I) 

(-/> A (/:OPTION ?C ?A2 
t/sTO-DO _?+TASK 

(CVT-EXPLOOE _?++0 _?++R) 

<•» 

(tihe-domain-rephrase 

_?++Q _?++R)J) 

« IF OUTPUT RELATION OOESN’T MENTION INPUT, TAKE FREQUENCY-DOMAIN 

(AND (-/> G (AND (/*» (DEN ?++R) 

l\ (_?+SVl _?+SV2) 
.’♦BODY)) 

(NOT (CONTAINS ?+BOOY 

11??| _?+SV11)>> 
(/:RULE-IN ?R1)> 

IF INPUT PREDICATE IS TRIVIAL, TATE TIME-DOMAIN 

(-/> G (AND (/i. (DEN ?♦♦(» 


* 
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t\ <_?+V) _’ + BODYI) 
(NOT (CONTAINS ’+BOOY 
t|??| _’+VI>)> 
(/:RULE-1N ’A2>) 

t FOR VERY HIGH FREQUENCIES, TIME DOMAIN UON’T UORK 

<-/> G (ANO </:SUBTASK (DEN ’+TASK) 
?SUP) 

(/!TASK-ACTION ?SUP 

(O-EXPLOOE ’+P>) 
(/«. (/:ENAB-STRTUS 
?SUP> 

ACTIVE) 

(O-FEATURE ?+P 
IRANGER FREQ-OP 

VERY-HIGH!)) 
(/iRULE-OUT ?A2)))))1 

GENERAL-OP*) 

j FREQUENCY-DOMAIN REPHRASING INFO 


(DEFMLA FREQ-DOM-REPH-DO-1 


l/iTO-DO ’TASK (FREQ-OOMAIN-REPHRASE ?+Q ’+R> <> 

(/sSEQ 

(/:FIND 

(\ (+FPT) 

(EXISTS (FP1 FP2 FPT) 

(FORAU (SI S2) 

(IMPLIES (ANO (IS SIGNAL ?S1) 

<(OEN ?+Q) ?S1) 

(IS SIGNAL ?S2> 

((DEN ?+R) ’SI ’S2>) 

(AND (•/> ’(FREQ-PICTURE 
(TFUN ’Sl)> 

?FP1) 

(«/> ’ (FREQ-PICTURE 
(TFUN ’S2)) 

’FP2) 

(FREQ-PIC-TRANS ’FP1 ’FP2 
’FPT) 

(./> ’(OEN ’+FPT) ’FPT))) 


)))) 


(\ (FPT) 

(/sINFER ’(SIG-FEATURE ’+Q ’+R IFREQ-TRANS _’+FPTl) 
<>) >>J> 


I GENERATING FREQUENCY-DOMAIN TRANSFORMATIONS 


(DEFMLA NFREQ-PICS-FILTER 

C/sCONSEQ (NOT (FREQ-PICS-FILTER ?FP1 

<(FF ?FREQ ?LM2) !#’FP2> ?C)) 



(HOT (FORflLl (LIU) 

(NOT (ELT (FF ?FREQ ?LH1) ?FP1>> ))J) 


(OEFHIB FREQ-TRfINS-LOU 

I/tCONSEQ (FREQ-TRRNS 7FP-IN 7FP-OUT (LOU-PfiSS ?f1)) 

(NOT (AND (FREQ-PICS-FILTER ?FP-IN ?FP-OUT ’FP-GONE) 
(FORflLl (FL F) 

(RNO (EQUIV (ELT (FF ?F ?FL> ’FP-GONE) 
(FORRLL (FL1 FI) 

(IftPLIES (ELT (FF ?F1 ?FL1) 
?FP-GONE) 

(/> ?F ?F1)> )) 

(/i. ?n 

(I1AX ’FP-GONE 
(\ (F G> 

(/> (FF-FREQ ?F) 

(FF-FREQ ?G)> 

)>)) >)>)) 

{SlflllRRLY FOR HIGH-PASS flNO BRNO-PASS 

(OEFflLfl FREQ-PICS-FILTER-I 

IFREQ-PICS-FILTER ?FP1 <> ?FPIJ) 

(OEFflLfl FREQ-PICS-FILTER-2 

t/:CONSEQ (FREQ-PICS-FILTER ?FP1 <(FF 7FREQ ?Lf12) !#?FP2> ?C» 
(NOT (RNO (ELT (FF ?FREQ ?LI11> ?FP1> 

(* (FF-SHRPE ?LH1) (FF-SHRPE ?U12)> 
(FREQ-PICS-FILTER (DEL (FF ?FREQ ?Lt11> ?FPI) 
?FP2 ?C)))I) 

(TYPES OF FREQ-TRRNS: (LOM-PflSS (CUTOFF|», (HIGH-PASS (CUTOFF|>, 

I (BANO-PRSS |CUTOFF |), (MIX (SIGNRL-PREO|) (ftOOULRTE...) 

(OEFflLfl LOU-PASS 

I/iftNTEC (NOT (O-SHRRO ?+P 

I\ (_?+V) (SIG-TRRNS (|??| _?tV> 

(FREQ-TRRNS 

(LOlf-PRSS _?+CUTOFF)))))) 
(CORE-OEV-TYPE ?+P ILOU-PRSS-fILTER _?+CUTOFFI)J) 


(OEFflLfl HIGH-PASS 

1/iflNTEC (NOT (D-SHRRO ?+P 

t\ (_?+V> (SIG-TRRNS (|??| _?+V> 
(FREQ-TRflNS 

(HIGH-PASS J+CUTOFF)))])) 
(CORE-OEV-TYPE ?+P (HIGH-PRSS-FILTER _?+CUTOFFl)J) 


(CHOOSING DEV-TYPES — 



(OEFHLA LINEAR-CROUPINC 

[-/> A (/:CHOICE k ?tsk ccore-dev-type j**p _?++oi> 

<-/> n (QUIESCENCE ?C> 

(-/> G (RND (/:OPTION ?C ?R1 
ICORE-OEV-TYPE 

(__?+♦?) C_7++D1J J> 

(/:OPTION ?C ?A2 

(CORE-DEV-TYPE (_?*+PJ t_?++D211> 
(LINERR-OEV-TYPE (DEN (OEM ?++D2)>> 

) 

(/iRULE-TOGETHER <?R1 ?R2> 

ICORE-DEV-TYPE _?++P 

(GROUP <_?+*01 _?*+D2>lI >)))) 


jGROUPS HAY BE EXPRESSED RS SEVERAL KINDS OF CASCADE 

(OEFHLA HAKE-GROUP-1 
I/:CONSEQ 

(/! T0-00 ?T (HAKE (GROUP <?X ?Y !#?Z>>) <?NAHE> 

(/:SEQ (ACQUIRE (GROUP ^OT—REST)). 

(\ (G) (HAKE (CASCADE ?OTl ?G)> >>> 

(NOT (AND (ELT ?DT1 <’X ?Y !#?Z>) 

(/•.« 7DT-REST (DEL ?OTl <?X ?Y !#?Z>))))1 

GENERAL-DP*) 


(DEFHLA HAKE-GROUP-2 

I/:TO-DO ?T (HAKE 
(HAKE (CASCADE 


(GROUP <?DT1 ?0T2>)) <?NAHE» 

?OTl m2))]) 


(DEFHLA HAKE-GROUP-3 

(/:TO-DO ?T (HAKE 
(HAKE (CASCADE 


(GROUP <?OTl ?DT2>)) <?NAHE> 
?OT2 ?DT1>)1) 


jAHPLIFIER IS A UIDE ("SUPERORDINATE") CATEGORY, FOR UHICH THERE ARE 
I SEVERAL SPECIFIC TYPES 

(OEFHLA AHP-DEV-TYPE (SUPERORDINATE-OEV-TYPE AHPLIFIER1) 

(DEFHLA SUB-CE (SUB-DEV-TYPE CE AHPLIFIER1) 

(DEFHLA SUB-CC (SUB-DEV-TYPE CC AHPUFIERI) 

(DEFHLA SUB-CB (SUB-DEV-TYPE CB AHPLIFER1) 

j IF HOOERATE V-GAIN, COHHON EHITTER 

(DEFHLA HOD-V-GAIN 

(-/> A (/: TASK-ACTION HSK (HAKE AHPUFIERI) 

(-/> A (/:SCOPE ?PTSK HSK) 

(-/> A </j POL ICY ?PTSK 

(D-NOTE (RANGER V-GAIN HODERRTE))) 
(/sTO-OO ?TSK (HAKE AHPLIFIER) <?OEV> 
(HAKE CE))))J 


GENERAL-DP*) 



I IF HIGH V-GRIN, SOME KIND OF N-STAGE 
(DEFHLA HIGH-V-GHIN 

(-/> fl (/!TASK-ACTION 7TSK (MAKE AHPLIFIER)) 

(-/> A </:SCOPE 7PTSK ?TSK) 

(-/> A </1POLICV ?PTSK 

(O-NOTE (RANGER V-GRIN HIGH))) 

(/iTO-DO ?TSK (HAKE AHPLIFIER) <?OEV> 
(HAKE N-STAGE))))) 

GENERRL-DP*> 


I IF VERY-HIGH, OP-AflP 
(DEFHLA VERY-HIGH-V-CAIN 

(-/> A </!TASK-ACTION ?TSK (HAKE AHPLIFIER)) 

(-/» A (/iSCOPE 7PTSK 7TSK) 

(-/> A (/iPOLICY 7PTSK 

(D-NOTE (RANGER V-GRIN VERY-HIGH))) 
(/:TO-DO 7TSK (HAKE AHPLIFIER) <?DEV> 
(HAKE OP-AHP))))! 

GENERAL-OP*) 


I IF VERY LOH FREQ OF OPERATION (E.G., DC) — DIFF AHP 
(DEFHLA VERY-LOM-FREQ 

I-/> A (/!TASK-ACTION nSK (HAKE AHPLIFIER)) 

(-/> A (/iSCOPE 7PTSK HSK) 

(-/> A (/iPOLICY 7PTSK 

(D-NOTE (RANGER FREQ-OP VERY-LOU))) 
(/:TO-DO ?TSK (HAKE AHPLIFIER) <?OEV> 
(HAKE DIFF-AHP))))) 

GENERAL-DP*) 


I IF HIGH INPUT Z, UP CC 
(DEFHLA HIGH-INPUT-Z 

t-/> A (/!TASK-ACTION ?TSK (HAKE AHPLIFIER)) 

<-/> A (/iSCOPE ?PTSK ?TSK) 

(-/> A (/iPOLICY 7PTSK 

(O-NOTE (RANGER INPUT-Z HIGH))) 
(/!TO-DO ?TSK (HAKE AHPLIFIER) <?DEV> 
(HAKE CC>)>>) 

GENERAL-OP*) 


t IF HIGH POUER GAIN, UP C.OHP-SYH AND PUSH-PULL 
(OEFHLA HIGH-POUER-GAIN 

t-/> A (/:TASK-ACTION HSK (HAKE AHPLIFIER)) 

(-/> A (/iSCOPE 7PTSK 7TSK) 

(-/> A (/iPOLICY 7PTSK 

(O-NOTE (RANGER P-GAIN HIGH))) 

(AND (/iTO-DO 7TSK (HAKE AHPLIFIER) <?DEV> 



GENERAL-OP*) 


moicE cohp-syhd 

</:TO-DO nSK (HAKE RHPLIFIER) <?OEV> 
(HAKE PUSH-PULL)))))) 


jIF LINEARITY REQUIRED, CE 
(DEFHLA LINEARITY 

I-/> A </:TASK-ACTION ?TSK (HAKE AHPLIFIER)) 

(-/> A (/:SCOPE 7PTSK ?TSK) 

(-/> A (/s POL ICY 7PTASK ?TSK 
(O-NOTE LINEAR)) 

(/!TO-DO ?TSK (HAKE AHPLIFIER) <?OEV> 
(HAKE CE))))) 

GENERAL-OP*) 

jIF HORE THAN ONE TYPE APPEARS, A CHOICE IS IN ORDER 

(DEFHLA CHOOSE-AHP 

t-/> A (/sCHOICE ?C EXEC 

I/sT0-00 J+TASK (HAKE AHPLIFIER) <_?+NAHE> 
_?+HETH0D)) 

{-/> G (/:= (DEN 7+TASK) 7AHP-TASK) 

(ANO • 

(/:PKT CHOOSE-AHP-PKT 

(PC 7AHP-TASK 7+TASK 7+NAHE 7+HETHOD) 
<-/> A (/:QUIESCENCE PC) 

(/:PKT QUI-CHOOSE-AHP-PKT 
(PC 7RHP-TASK 7+TASK 
7+NAHE P+HETHOO)))) 

(-/> G (/:SCOPE ?PTSK 7AHP-TASK) 

TRUE)))) 

GENERAL-OP*) 


; IF HIGH POUER AND LINEARITY ARE REQUIREO, REPLACE POUER-AHP 
j OPTION UITH LINEARIZEO POUER-AHP 

(DEFHLA LINEAR-POUER 

(-/> A (/sSCOPE ’PTSK1 7AHP-TASK) 

(-/> G (AND (/s POL ICY PPTSK1 (D-NOTE LINEAR)) 

</:SCOPE 7 PTSK2 7AHP-TASK) 

(/:POLICY ?PTSK2 

(O-NOTE (RANGER P-GAIN HIGH))) 
(./> ’(DEN 7+PTSK2) 7PTSK2)) 

(-/> A (/:OPT ION ?C ?R1 

I/:TO-DO _?+TASK (HAKE AHPLIFIER) 
<_?+NAHE> (HAKE _?+OT)I> 


(-/> G 

(OPT-SUPPORT PHI 

1/1 POLICY _?+PTASK2 
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.’♦ABOVE-ACT)) 
(/(RULE-TOGETHER <?R1> 

1/iTO-OO _?+TASK (MAKE AMPLIFIER) 
<_?+NAME> 

</iSEQ (MAKE _?+DT) 

(\ (?X) 

(/(OO-ALL 
<(LINEARIZE ?X)> 
(/(OUTPUT <?X>)> ) 

))))))] 

CHOOSE-AMP-PK T) 


jQUIESCENCE PKT 

(DIFFERENTIAL DIAGNOSIS BETUEEN CE RNO N-STRGE 
(OEFfILfl OIFF-CE-N-STRGE 
t-/> R (/(QUIESCENCE ?C) 

(-/> G (RNO (/!OPTION ?C ’R1 

1/iTO-OO .’♦TASK (HAKE AMPLIFIER) <?_+NAHE> 
(HAKE CE)I) 

(/(OPTION ?C ?R2 

I/:T0-00 .7+TASK (HAKE AMPLIFIER) <_?+NAME> 
(MAKE N-STAGE)))) 

(AND 

<-/> G (AND (/(SCOPE ?PTSK ’AMP-TASK) 

(/(Pol icy ?PTSK 
(O-NOTE 

(RANGER BANOHIOTH HIGH)))) 
(/(RULE-OUT ?R1)) 

(-/> G (NOT (EXISTS (PTSK) 

(AND (/(SCOPE ’PTSK ?AMP-TASK) 
(/(POLICY ’PTSK 

(O-NOTE (RANGER BANOUIOTH 

HIGH)))) )) 

(/(RULE-OUT ?A2)>)>I 

CHOOSE-AMP-PKT) 


t *F ONE OPTION HAS SUGGESTED BECAUSE OF ITS INPUT-Z (E.G., 
j COMMON-COLLECTOR), RNO ANOTHER FOR SOMETHING ELSE, 

I YOU MAY CASCADE THEM 

(OEFMLA INPUT-CASCADE 

t-/> A (/(OPTION ?C ?A1 

t/( TO-DO .T+TASK (MAKE AMPLIFIER) <_?+N> 

(MAKE _?+DTl))) 

(-/> G (OPT-SUPPORT ?A1 

(/(POLICY .’+PTRSK 

(O-NOTE (RANGER INPUT-Z _?+RAN)>)) 

(-/> A 

(/(OPTION ?C ?AZ 

(/(TO-DO .’+TRSK (MAKE AMPLIFIER) <_?+N> 
(MAKE _?+DT2))) 
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CHOOSE-RtlP-PKT) 


<-/> C (NOT (« ?R1 ?R2)) 

(/:RULE-TOGETHER <?fll ?R2> 

t/t TO-DO _’+TRSK (MAKE AMPLIFIER) 
<_?+N> 

(HAKE (CASCADE _?*DT1 
_?+DT2 
))))>))] 


(DEFMLR OPT-SUPPORT {-/> C (AND </:OPTION-SUPPORT ?OPT ’FHLRS) 

(ELT ’+F ’FNLRS) 

(OR <:. ?+F ?+S) 

(SUPPORTS ?+S ?+F))) 
(OPT-SUPPORT ?OPT ?+S)I 
GENERAL-DP*) 


(DEFMLR SUPPORT-OEFN [-/> C (RND (/:DO ?+S ?P ?! ?+F2) 

(OR (:» ?+Fl ?+S> 

(SUPPORTS ?+Fl ?+S>>) 
(SUPPORTS ’+F1 ?+F2)J 
GENERAL-DP*) 


(OEFHLR MAKE-CASCADE 

t/iTO-DO ’TASK (MAKE (CRSCROE ?OTl ?0T2)> <?NEHDEV> 

(/:OO-SUBNET (CRSCflOE-PLRN ?OTl ?0T2) <CASCADE-NRME>>)) 

(DEFMLA CRSCROE-PLRN-NET 

!-/> R (/iPLAN-INSTANCE ’PI (CRSCROE-PLRN ?OTl ?0T2) ?SUP) 

(RND (STASK (MAKER-1 ’PI) ’SUP <> 

(\ () (MAKE ’DTI) ) <’ (FIRST-OEV ?PI)>) 

(STASK (MAKER-2 ’PI) ’SUP <> 

(\ () (HALE ’OT2) ) <’(SECOND-OEV ?PI)>) 

(STASK (GRABBER ’PI) ’SUP <> 

(\ () 

(GRABBfl (\ (X) 

((1RIN-DEV-TYPE 

’X (CASCADE ’OT1 ?DT2)) )) ) 

<’(CASCRDE-NAHE ?PI)>) 

(STASK (COUPLER ’PI) ?SUP 

<’ (FIRST-DEV ’PI) '(SECOND-DEV ?PI)> 

(\ (D1 02) (COUPLE ?D1 ’02) ) 

<>) 

(STASK (COMPONENTS-NAMER ’PI) 

<’ (CASCADE-NAME ’PI) 

’(FIRST-DEV ’PI) ’(SECOND-DEV ?PI)> 

(\ (C 01 D2) 

(/:INFER ’(COMPONENTS ’C <?01 ?02>) <>) > 

<>) 

(/:MRIN (GRABBER ’PI) ?SUP))I 



GENERAL-DP*) 


jUSE THE HOST GENERAL VERSION OF A CIRCUIT IN A CASCADE 

(OEFHLA COUPLE-GENERAL-1 

I-/> A (/(CHOICE ?C EXEC 

t/iTO-DO (HRKER-1 _?+PI> (HAKE _?+DT) <_?+OEV> 
J>+HAY1) 

(-/> G (AND (*/> ’(OEN ?+OT) ?OT) 

(HOST-GENERAL-SPEC TOT ?SPEC-DT) 

(■/> ’(OEN ?+SPEC-OT) 7SPEC-OT)) 

<-/> A </iOPTION ?C ?A 

I/(T0-00 (HAKER-1 _?+PI) (HAKE _?+OT) 
<_?+DEV> 

(HAKE _?*SPEC-DT)I) 

(/(RULE-IN ?A)))J) 


(OEFHLA COUPLE-GENERAL-2 

t-/> A (/(CHOICE ?C EXEC 

I/(TO-DO (MAKER-2 _?+PI) (HAKE _?+OT) < ?+OEV> 
_?+WAYl) 

(-/> G (ANO (*/> ’(OEN ?+DT> TOT) 

(HOST-GENERAL-SPEC ?DT 7SPEC-OT) 

(*/> ’(DEN 7+SPEC-DT) 7SPEC-DT)) 

(-/> A (/(OPTION ?C ?R 

I/(TO-DO (HAKER-2 _7+PI> (HAKE _7+OT> 
<_7+DEV> 

(HAKE _7+SPEC-OT)I) 

(/(RULE-IN 7A))))) 


(CIRCUIT ALTERATION ACTIONS 


(DEFHLA FIXING-CHANGES-TOPOLOGY ITOPO-CHANGE-ACTION-FUN FIX)) 


(DEFHLA VS-FIX-V 

I/sTO-DO ?TASK (FIX ’(V 7NOOE)) <> 

(CONFIG (VOLTAGE-SOURCE) 

(\ (VS) 

<(TRHINS-CONNECT (#1 TVS) 7NODE)> )))) 


(DEFHLA VD-FIX-V 

t/(TO-DO 7TASK (FIX ’(QUIESCENT (V 7NODE))) <> 
(CONFIG <VO NODE NOOE> 

(LAHBDA (VO N1 N2> 

<(CONSTRAIN <’(V TNI) ’(V ?NODE)> 

(\ (VI V) (/» m ?V) )) 

(CONSTRRIN <’(V ?N2) ’(V ?NOOE)> 

(\ (V2 V) (/> ?V 7V2) )) 
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(NOOES-HERGE ’N1 (TOP 7VO)) 
(NODES-HERGE ?N2 (BOT ?VO>) 
(NODES-HERGE ’NOOE (HID ?VD))> >>J 

GENERAL-DP*) 


(DEFHLA DIP-FIX C/1TO-DO 7TRSK (FIX ’ (- ?X1 7X2)) <> 

(/:DO-ALL <(FIX ’7X1) (FIX '7X2)>)I) 


jBIASING 

(DEFHLA BIRS-CHRNGES-TOPOLOGY ITOPO-CHRNGE-RCTION-FUN BIRS1) 

(DEFHLA BJT-BIRS 

1 /:RNTEC (NOT (DEV-TYPE ?Q BJT)) 

(/iTO-DO ’TASK (BIRS ?Q ACTIVE) <> 

(/:DO-SUBNET (GENERAL-BIRS-PLRN ?Q) 7TRSK <>)))) 

(DEFHLA BJT-BIAS-NET 

C/iANTEC (NOT (/:PLRN-INSTANCE 7PI (GENERAL-BIAS-PLAN 7Q) 7SUP)) 
(AND (STASK (VBE-FIXER 7PI) 7SUP <> 

(\ () (FIX ’(- (V (BASE ?Q)) (.V (EHI ?Q)))) ) 

<>) 

(STASK (CB-BIASER 7PI) 7SUP <> 

(N O (REVERSE-BIAS (CB-JUNCTION ?Q)) ) <>) 

(STASK (IC-FIXER 7PI) 7SUP <> 

(\ () (FIX Ml (COL ?Q))) ) <>) 

(/:MAIN (VBE-FIXER 7PI) 7SOP) 

(/iHRIN (IC-FIXER 7PI) 7SUP)>J 

GENERAL-DP*) 

(DEFHLA TYPICAL-BJT-ONE-STAGE-BIAS 
[-/> A (/:PLAN-INSTANCE 7PI 

(TYPICAL-BJT-ONE-STAGE-BIAS-PLRN ?Q) 7SUP) 

(AND 

(STASK (BVD 7PI) ’SUP <> 

(\ () (ACQUIRE VO) ) <’(BVD ?PI)>) 

(STASK (SUPPLY-POUER 7PI) 7SUP <> 

<\ () (ACQUIRE VS) ) <’(POUER-SUPPLY 7PI)>) 

(STASK (RESIS-GETTER 7PI) 7SUP <> 

(\ () (ACQUIRE RESISTOR) ) <’(RE ?PI)>) 

(STASK (BASE-SETTER 7PI) 7SUP <MBVO ?PI)> 

(\ (VO) (TRfllNS-CONNECT (BASE 7Q> (HID 7VD)) ) 

<>) 

(STASK (COLLECTOR-POUER 7PI) 7SUP 
<’(POUER-SUPPLY ’PI)> 

<\ (PS) (DEV-INSERT TPS (CNOOE ?Q) 

(#2 ’PS) 

(NOOE-TERHINALS (CNODE ?Q)) 

(#1 ’PS) <>) ) 

<>) 

(STASK (EMITTER-HUNGER 7PI) 7SUP <’(RE ?PI)> 


II 



Appendix 3 


237 


(\ (R> (DEV-INSERT ?R (ENOOE 7Q> 

?R) < (Efll ?Q)> 

(#2 ?R> 

(DEL (EMI ?Q) 

(NOOE-TERHINRLS (ERODE ?Q)>>) > 

<>) 

(REDUCE <(BVD ’PI) (BRSE-SETTER ?PI)> 

(VBE-FIXER ?PI)) 

(REOUCE <(SUPPLY-POWER ?PI) (COLLECTOR-POUER 7PI)> 
(CB-BIASER 7PI)) 

(REOUCE <(RESIS-GETTER 7PI) (ENITTER-NUNGER ?PI)> 
(IC-FIXER ?PI>> )I) 


(DEFNLR SPEC-TYPICRL-BJT 

ISPEC-SCHEflR (TYPICRL-BJT-ONE-STRCE-BIRS-PLRN ?Q) 
(GENERAL-BIRS-PLRN ?Q)D 


;COUPLING HRS BEEN SPECIALIZED TO BJT RHPLS. 

(DEFNLR COUPLING-CHRNGES-TOPOLOGY (TOPO-CHRNGE-RCTION-FUN COUPLED 
(DEFNLR COUPLE-DO-i 

l/rTO-DO 7TASK (COUPLE ?D1 7PORT1 7PORT2 702) <> 

(/:DO-SUBNET (GENERAL-COUPLING-PLRN 701 7P0RT1 7P0RT2 702) 
7TRSK <>)J) 


(DEFIILfl COUPLE-NET 

t/ifiNTEC (NOT (/:PLAN-INSTANCE 7PI 

(GENERAL-COUPLING-PLRN 701 7P0RT1 7PORT2 702) 
7SUP)) 

(RND (STRSK (SIGNAL-NEDIUN-CHOOSE 7PI) 7SUP <> 

(\ 0 
(/:FINO 
(\ (n> 

(ELT ’ll <VOLTAGE CURRENT>) )) > 

<’(NEDIUI1 ?PI)>) 

(STASK (COUPLE-TYPE-CHOOSE 7PI) 7SUP <> 

(\ () 

(/(FIND 
(\ (CT) 

(ELT 7CT 

<OIRECT CAPACITIVE 
INDUCT IVE>) )) ) 

<’(COUPLE-TYPE 7PI)>) 

(STRSK (CONVERT-PORT-1 7PI) 7SUP <’(NEOIUN ?PI)> 
(\ (ID (PORT-CONVERT 7P0RT1 ?N) ) 

<>) 

(STRSK (CONVERT-PORT-2 7PI) 7SUP <’(NEOIUN 7PI)> 
(\ (H) (PORT-CONVERT 7P0RT2 ?H) ) 
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<>) 

(STASK (CONNECTOR ?PI> 7SUP <’(COUPLE-TYPE ?PI)> 
(\ (TYPE) 

(PORTS-CONNECT 7PORT1 7PORT2 7TYPE) ) 

<>) 

</!SUCCESSOR (SIGNAL-MEDIUH-CHOOSE 7PI) 
(CONVERT-PORT-1 ?PI>) 

(/iSUCCESSOR (SIGNAL-MEDIUM-CHOOSE ?PI) 
(CONVERT-PORT-2 7PI)) 

(/:SUCCESSOR (CONVERT-PORT-1 7PI) 

(CONNECTOR 7P1)) 

(/:SUCCESSOR (CONVERT-PORT-2 7PI) 

(CONNECTOR ?PI)> 

(/iflRIN (CONNECTOR ?PI) 7SUP) 

)) 

GENERAL-DP*) 


(DEFfILR COUPLE-BEFORE-BIAS 

t-/> A </i TASK-ACTION ?CT (COUPLE 701 7PRT1 7PRT2 ?02)> 
(-/> G (ANO (COMPONENTS 701 70ICS) 

(COMPONENTS ?D2 ?D2CS) 

(OR (ELT ?Q 701CS) (ELT 7Q 702CS)) 
(MAIN-OEV-TYPE ?Q BJT)) 

(/:SUCCESSOR ?CT (BIASER ?Q ?HOOE»»)J» 


jSPECIFIC SITUATIONS — 

(OEFULA COUPLE-CE-X-H1NTS 

l-/> A (/:TASK-ACTION ’CT (COUPLE 701 (OUTPORT 701) 7PRT2 702)) 
(-/> G (OEV-TYPE ?D1 CE) 

(/sPKT CE-COUPLE-HINTS (7CT 701 7PRT2 702) 

(/:TO-DO 7 CT (COUPLE 701 (OUTPORT 701) 

7PRT2 702) <> 

(/:00-SUBNET 

(CE-DIR-VOL-COUPLE 701 7PRT2 702) 

<>)) 

(/i TO-DO 7CT (COUPLE 701 (OUTPORT 701) 

7PRT2 702) <> 

(/:DO-SUBNET 

(CE-OIR-CUR-COUPLE 701 7PRT2 702) 

<>)) 

(/:TO-DO >CT (COUPLE 701 (OUTPORT 701) 

7PRT2 702) <> 

(/i00-SUBNET 

(CE-CAP-VOL-COUPLE 701 7PRT2 702) 
<>))))}) 


(DEFfILR COUPLE-CC-X-HINTS 

[-/> A (/.-TASK-ACTION 7CT (COUPLE 701 (OUTPORT 701) 7PRT2 7D2)) 
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(-/> C (DEV-TYPE ?01 CC) 

(/.-PtCT CC-COUPLE-HINTS <?CT 701 7PRT2 ?D2) 
(/iTO-OO 7CT (COUPLE ?01 (OUTPORT 701) 
7PRT2 ?D2) <> 

(/!DO-SUBNET 

(CC-DIR-VOL-COUPLE ?Dl 7PRT2 702) 
«))>>)) 


(DEFHLA CE-DIR-VOL-COUPLE-PLRN 

l-/> A (/:PLAN-INSTANCE ?PI 

(CE-DIR-VOL-COUPLE ?01 7PRT2 7D2) 7SUP) 

(AND <»/> ’ (MEOIUfl ’PI) VOLTAGE) 

<=/> ’(COUPLE-TYPE 7PI) OIRECT) 

(/iREOUCEO (SIGNAL -HEOIUH-CHOOSE 7PI)) 

(/:REDUCED (COUPLE-TYPE-CHOOSE ?PI>> 

(STASK (GET-RESISTOR 7PI) 7SUP <> 

(\ () (ACQUIRE RESISTOR) ) <’(RESISTOR ?PI)>) 
(STHSK (GET-POHER-SUPPLY 7PI) 7SUP <> 

(\ O (ACQUIRE VOLTAGE-SOURCE) ) <•(VS ?PI)>) 
(STASK (BJT-FINDER ?PI> 7SUP <> 

(\ <) 

(/:FIND 
(\ (Q) 

(EXISTS (CS) 

(AND (COHPONENTS 701 7CS) 

(ELT 7Q 7CS) 

(HAIN-DEV-TYPE 7Q BJT)) ))) ) 

<’(TRANSISTOR ?PI)>) 

(STASX (UIRER-1 7PI) 7SUP 

<’(RESISTOR 7PI) ’(TRANSISTOR ?PI)> 

<\ (R Q) (TRtllNS-CONNECT (#2 7R) (COL 70)) ) 

<>) 

(STASK (UIRER-2 7PI) 7SUP 
<’ (RESISTOR 7PI) MVS 7PI)» 

(\ (R VS) (TRHINS-CONNECT (#1 7R) (#2 7VS)) ) 

<>) 

(REDUCE <(GET-RESISTOR 7PI) (UIRER-1 ?PI)> 
(CONVERT-PORT-1 7PD) 

(-/> A («/> ’(TRANSISTOR 7PI) ?Q) 

(-/> A (/:PLAN-INSTANCE 7BIAS-PI 

(GENERAL-BIAS-PLAN ?Q) 7SUP-BIAS) 
(REDUCE <(GET-POUER-SUPPLY 7PI) 
(UIRER-2 7PI)> 

(CB-BIASER 7B1AS-PI))))))) 


(OEFMLA SPEC-CE-DIR-VOL 

ISPEC-SCHEflA (CE-DIR-VOL-COUPLE ?D1 7PRT2 702) 

(GENERAL-COUPLING-PLAN ?D1 (OUTPORT 701) 
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7PRT2 702)J) 


(DEFHLR PORT-CONVERT 

t-/> C (AND (I-PORT 7PRT) 

(»/> ’ (PORT-TERHINRLS 7PRT) <?TRniNl 7TRIUN2>) 

(=/> MNOOE-TERtllNALS 7TRHIN1) 7TS)) 

</iTO-DO 7TASK (PORT-CONVERT 7PRT CURRENT VOLTAGE) <> 
(CONFIG <RESISTRNCE> 

(\ (R) 

<(/:FORtC 

(OEV-INSERT ?R 7TRHIN1 

(#1 ?R) 7TS (#2 ?R) <>) 

(\ () 

<(RELR0EL-PORT 7PRT I-PORT V-PORT) 
(CONSTRAIN <’(I (#1 ?R)) (I ?TRMN1)> 

(\ (IR IT) 

(/>/> (RBS 7IR) 

(RBS ?IT)) ))> ))> )))J) 


(OEFfILfl RELABEL 

1/iNOD-HANIP 7TSK (RELRBEL-PORT 7PRT 70L0 7NEU) 
<’(70L0 7PRT)> <’(7NEU 7PRT)>I) 


(DEFHLA ACQ-NODE INOT (REUSABLE NODE))) 

(DEFflLA PRM-NOOE IPRIHITIVE-DEV-TYPE NODE) GENERAL-OP*) 


(DEFHLA 2-TERfUNAL-OEFN 

l-/> A (DEV-TYPE 7X 2-TERfllNAL) 

(/:PKT 2-TERflINAL-PKT (?X) 

(TERMINAL-NAtlES 7 X «»1 #2>) 

(CONSTRAINT <’(I (#1 ?X)) ’(I (#2 ?X))> 

(\ (II 12) (. <♦ 711 712) 0) )) 

(CONSTRAINT <’(V ’X) ’(V (#1 ?X)> MV (12 ?X))> 
(\ (V VI V2) 

(= ?V (- ?V1 7V2)) )))J 

GENERAL-DP#) 


(DEFHLR PR1H-RESIS (PRIMITIVE-DEV-TYPE RESISTOR]) 

(DEFHLA RESISTOR-OEFN 

(-/> A (DEV-TYPE ’X RESISTOR) 

(/iPKT RESISTOR-PKTPX) 

(OEV-TYPE n 2-TERHINAL) 
(CONTROL ?X R REALS 1.0) 



(CONSTRAINT 

(CONSTRAINT 


<’<R ?X)> 

(LAMBDA (R) </>* ?R 8 ' 8 ’ 

<. ( R ?x> mv (#1 nu 
’(V (12 ?x» Ml (#1 2*»> 


(LAMBDA (R VI V2 !l> 

,» (* ?ll ?R> <- 


?V1 ?V2)) 


)))I 


GENERAL-0P#> 

,0tm. RCO-RESISTOR WOT wEusmu «esisio»i> 


(DEEPER prip-oeeo ipripitive-oemtpe .PE.,. 

(OEFULA open-oefn 

r-/> A (DEV-TYPE ’X OPEN) 

(AND (DEV-TYPE ?X 2-TERMINAL) 

(CONSTRAINT <MI (« ?X))> 

(LAMBDA (I> <« 71 81 '' 

(CONSTRAINT <MI (12 ?X))> 

(LAMBOA (U <■ 81 ,,n 

GENERAL-OP*> 

(DEEPER PRW-SHOPT (RRIPITIRE-OE.-TYRE SR0.I1> 

(DEEPER »*Y E ( ". TIpE „ SHORT) 

,„«D (OEV-TVPE » E-tE."'^ 

(COHSTRRIRT 


",lambda (VI V2) (. ?Vl ?V2) )») 


orllFDOl nP*^ 


(DEFMLA prim-cap 
(OEFMLA ACO-CAP 


(PRIM1TIVE-DEV-TYPE CAPAC1T0R)> 
(NOT (REUSABLE CAPAC1TOR)1» 


(DEF „LA cap-o^ oev _ type cflpflcnoR) 

(/iPKT CAP-PXT (?X) 

(OEV-TYPE ?X 2-TERMINAL) 

(CONTROL ?X C REALS 1.2) 

(CONSTRAINT <MC ?X)> 

(LAMBDA (C) (/>• 7C 8,B ’ 

(N (DC) MOEV-TYPE »X CAPACITOR)) 

(T (DC) (DEV-TYPE ?X OPEN)) 

(N (SSS ’S) MOEV-TYPE ?X CAPACITOR)) 
a (SSS TS) (AND (OEV-TYPE ?X RESISTOR) 


)) 


(N (HIGH-FREQ* 
(T (HIGH-FREQ) 


(DEV-TYPE ?X CAPACITOR)) 
(OEV-TYPE ?X SHORT)))1 


GENERAL-OP*) 
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(DEFHLA PRIH-INDUC IPRIHITIVE-DEV-TYPE INOUCTORJ) 

(0EFI11R INOUC-DEFN 

I-/> A (OEV-TYPE n INDUCTOR) 

(/!PKT INDUC-PKT (’X) 

(DEV-TYPE ’X 2-TERniNRL) 

(CONTROL ?X L REALS 1.5) 

(CONSTRAINT <’(L ?X)> 

(LRHBDR (L) (/>« ?C 0.0) )> 

(N (DC) ’(OEV-TYPE ?X INDUCTOR)) 

(T (DC) (DEV-TYPE ?X SHORT)) 

(N (SSS ?S> ’(OEV-TYPE ?X INDUCTOR)) 

(T (SSS ?S) (RND (OEV-TYPE ?X RESISTOR) 
(=/> ’(R ?X> 

(« (L 7X) ?S)>)) 

(N (HIGH-FREQ) (OEV-TYPE ?X INDUCTOR)) 

(T (HIGH-FREQ) (DEV-TYPE ?X SHORT)))J 

GENERAL-DP*) 


(DEFHLA COHP-XFHR ICOHPOSITE-DEV-TYPE TRANSFORHER)> 

(OEFHLA XFHR-DEFN 

t-/» A (DEV-TYPE ?X TRANSFORHER) 

(/:PKT XFHR-PKT (’X) 

(TERHINRL-NAHES ?X <<L1 #L2 #R1 #R2>) 

(CONTROL ?X TURNS-RRTIO REALS 1) 

(CONSTRAINT <’(TURNS-RRTIO ?X)> 

(\ (N) (/> ?N 0) )) 

(CONSTRAINT <’(I <#L1 ?X)> ’(I (*L2 ?X))> 

(\ (11 12) <« (+ ?I1 712) 8) )) 

(CONSTRAINT <’(I (*R1 ?X>) ’(I (*R2 ?X))> 

(\ (13 U) (» (+ 713 ?U) 8) >) 

(CONSTRAINT <’(V (HI ?X)> ’(V (IL2 ?X)) 

’(V (#R1 ?X)) ’(V (IR2 ?X)) 

’(I (HI ?X>) MI (#R1 ?X))> 

(\ (VL1 VL2 VR1 VR2 IL IR) 

(= (+ (* (- 7VL1 7VL2) 7IL) 

(* (- 7VR1 7VR2) 7IR)) 

8 ) ))>!> 

; A TRANSFORHER HAY CONSIST OF TUO INDUCTORS 

(DEFHLA OERIVEO-XFHR 

l/: TO-DO MASK (HRICE TRRNSFORHER) <?NAHE> 

(/iOO-SUBNET (BUH-TUO-INDUCTQRS) <XFHR>)I 
GENERAL-OP*) 

(DEFHLA BUH-INOUCTORS-NET 

t-/> A (/:PLAN-1NSTRNCE ?PI (BUH-THO-INDUCTORS) 7SUP) 

(ANO (STRSK (GET-INDUC-1 7PI) 7SUP <> 


II 
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<\ (> (ACQUIRE INOUCTOR)) <’(LI ’PI)>) 

(STASK (GET-1NDUC-2 ’PI) ?SUP <> 

(\ () (ACQUIRE INDUCTOR)) <ML2 ’PI)>) 

(STASK (ABRA ’PI) ?SUP <* (LI ?PI) ’(L2 ’PI)> 

(\ (LI L2) (GRAB8A 
(\ (X) 

(AAIN-DEV-TYPE ?X TRANSFORAER) ))) 

<’(XFAR ?PI)>) 

(STASK (CADABRA ?PI) ’SUP 

<’ (LI ’PI) ’ (L2 ’PI) '(XFAR ?PI)> 

(\ (LI L2 XFAR) 

(/:INFER MCOAPONENTS ’RARE <?L1 ’L2>) 

<>) ) 

<>) 

(/lAAIN (ABRA ’PI) ’SUP))] 

GENERAL-DP*) 


(DEFALA IDEAL-VS tIOEAL-DEV-TYPE VOLTAGE-SOURCEl) 

(DEFALR REUSABLE-VS (REUSABLE VOLTAGE-SOURCED 
(DEFALA VS-OEFN 

l-/> A (DEV-TYPE ’X VOLTAGE-SOURCE) 

(AND (DEV-TYPE ?X 2-TERN I NAD 
(CONTROL V ’X REALS 1) 

(CONSTRAINT <MV ?X> * (V (#1 ’X)) ’(V (« ?XD> 
(\ (V VI V2) (. ?V <- ?V1 ?V2)) )))]) 

(DEFALA PRIA-BJT IPRIAITIVE-OEV-TYPE BJTJ) 

(DEFALA BJT-DEFN 

t-/> A (DEV-TYPE ’Q BJT) 

(MPKT BJT-PKT (?Q) 

(TERAINAL-NAAES ?Q <BASE EAI COL>) 

(CONTROL POLARITY ’Q -1» D jNPN VS PNP 
(CONTROL BETA ’Q (INTERVAL 1» 58B) 18.) 
iBETA CONTROLLABLE UP TO ORDER OF AAGNITUDE 
(CONTROL RPI ’Q REALS 1.5) 
jINCREAENTAL BASE RESISTANCE 

(-/> A (NODE ?Q ’A) 

(STASK (BIASER ’Q ’A) (DEEP-FREEZE ’A) <> 

(\ () (BIAS ’Q ’A) ) <>)) 

(-/> A (AOOE ’Q ACTIVE) 

(AND 

(CONSTRAINT <’(I (BASE ?Q)) 

’(I (COL ’QD ’(BETA ’Q)> 
(LAABDA (IB IC BETA) 

U ’IC <* ’BETA ’IB)) )) 

(CONSTRAINT <’ (I (COL ’QD MI (EAI ’Q))> 
(LAABOA (IC IE) 


IT 
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<• u ?ic ?iE> 0.01 >) 

(CONSTRAINT <’(I (BASE ?Q))> ZEROP) 
(CONSTRAINT <’(V (BASE ?Q>> ’(V (EMI ?Q)) 

’(POIARITY ?0)> 

(LAABOA (VB VE S) 

(• (- ?VB ?VE) (* 0.6 ?S)> >) 

(INEQ (V (BASE ?Q)> (V (EM ?Q)> 

(POLARITY ?Q)) 

(INEQ (V (COL ?Q)) (V (BASE ?Q>> 

(POLARITY ?Q)> 

(INEQ (I (COL ?Q>) B (POLARITY ?Q>> 

(INEQ (I (BASE ?Q>) 0 (POLARITY ?Q)) 

(INEQ 8 (I (EM ?Q)) (POLARITY ?Q>))» 

(-/> A MODE 7 Q CUTOFF) 

(AND 

(CONSTRAINT <*(I (COL ?Q))> ZEROP) 
(CONSTRAINT <’(I (BASE ?Q))> ZEROP) 
(CONSTRAINT <’(I (EM ?Q))> ZEROP))) 

(-/> A MODE 7 Q SATURATED) 

(CONSTRAINT <’(V (COL ?Q)> ’(V (EM ?Q)> 
’(POLARITY ?Q)> 

(LAABOA (VC VE S) 

(- ?VC (+ ?VE (// (* 0.6 ?S) 2.0))) ))) 

(N (INC) ’(CONSTRAINT <’(V (BASE ?Q>) ’(V (EAI ?Q>) 
’(POLARITY ?Q)> 

(LAABDA (VB VE S) 

(» (- ?VB ?VE) (* 8.6 ?S)) ))) 

(T (INC) (CONSTRAINT <’(V (BASE ?Q)) ’(V (EAI ?Q)> 

’(I (BASE ?Q)> ’(RPI ?Q) > 

(\ (VB VE IB R) 

(* (- ?VB ?VE) (* ?IB ?R)) ))) 


)I 

GENERAL-DP*) 


(DEFALA INEQ—1 

t-/> A (INEQ ?X ?Y ?S> 

(AND (-/> C (/> ?S 8) (/> ?X ?Y)) 

(-/> C (/< ?S B) (/< ?X ?Y>)>1) 

(COMPOSITE DEVICES 

(OEFALA SIG-TRANSER-GLORIA-AUNDI 

(-/> A (DEV-TYPE 7 X SIG-TRANSER) 

(PORTS ?X <(IMPORT 7 X) (OUTPORT ?X)>) 1) 


(OEFALA NOOES-OECL-DEFN 

!-/> A (NOOES ?OEV 7 N00E-TUP) 

(-/> G (ELT ?N 7NOOE-TUP) MAIN-OEV-TYPE ?N NODE))) 



GENERAL-OP#) 


(DEFfILfl PORTS-OECL-DEFN 

t-/> R (PORTS ’DEV ’PORT-TUP) 

<-/> G (ELT ?PRT ’PORT-TUP) (flRIN-OEV-TYPE ’PRT PORT))l) 

(DEFfILfl AfIP-SIG-TRANS (SUB-DEV-TYPE AMPLIFIER SIG-TRANSER)) 


(OEFMLfl CE-BRS1C IBRSIC-OEV-TYPE CEJ) 

(DEFfILfl CE-flMP (SUB-OEV-TYPE CE RfIPL(FIERI) 

(DEFfILfl ftOST-GEN-CE (flOST-GENERRL-SPEC CE GENERRL-CE)) 

(OEFULR CE-OEFN 

[-/> fl (OEV-TYPE ’CE GENERRL-CE) 

(/iPKT CE-PKT (?CE) 

(COMPONENTS ?CE <(Q ’CE)>) 

(NOOES ?CE <(BNOOE ’CE) (ENOOE ?CE> (CNOOE ’CE)>) 

(OEV-TYPE (Q ’CE) BJT) 

(NODE (Q ’CE) ACTIVE) 

(/sSUBTRSK (BIRSER (Q ’CE) ACTIVE) (OEEP-FREEZE ’CE)) 
(/iTO-DO (BIRSER (Q ’CE) ACTIVE) ’fl <> 

(/:DO-SUBNET 

(TYPICRL-BJT-ONE-STflGE-BIRS (Q ’CE)) <>)) 


(•/> ’(NODE-TERMINALS (BNOOE ’CE)) <(BASE (Q ?CE))>) 
(•/> ’(NODE—TERMINALS (ENOOE ?CE>> <(EHI (Q ?CE))>) 
(=/» ' (NODE-TERMINALS (CNOOE ’CE)) <(COL (Q ’CE))>) 


GENERAL-DP*) 


(I-PORT (INPORT ?CE>> 

(PORT-TERMINALS (INPORT ?CE) 

<(BNOOE ?CE) (ENOOE ?CE)>) 
(I-PORT (OUTPORT ’CE)) 

(PORT-TERNINRLS (OUTPORT ’CE) 

<(CNOOE ’CE) (ENOOE ?CE)>) 


)) 


(OEFNLfl OEFRULT-CE (DEFAULT-SPEC CE TYPICAL-CEJ) 

(DEFfILfl DERIVRTION-TYP-CE (OERIVEO TYPICAL-CE GENERAL-CEI) 

(DEFfILfl TYPICAL-CE-OEFN 

I/jflNTEC (NOT (OEV-TYPE ’TYP-CE TYPICAL-CE)> 

(/iPFT TYPICAL-CE-PKT (’TYP-CE) 

(OEV-TYPE ’TYP-CE CE) 

(COMPONENTS ’TYP-CE <(Q ’TYP-CE) (R1 7TYP-CE) 
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(R2 ’TYP-CE) (RE 7TYP-CE) 
(RL 7TYP-CE)>) 

CflRIN—DEV-TYPE (Q ’TYP-CE) BJT) 

(MODE (Q 7TYP-CE) RCTIVE) 

(HRIN-DEV-TYPE (R1 ’TYP-CE) RESISTOR) 

(HRIN-DEV-TYPE (R2 ’TYP-CE) RESISTOR) 

(HRIN-DEV-TYPE (RE ?TYP-CE) RESISTOR) 
(MRIN-DEV-TYPE (RL ?TYP-CE) RESISTOR) 

(NOOES ’TYP-CE «<BNOOE ’TYP-CE) (CNODE 7TYP-CE) 
(ENOOE ’TYP-CE) (GNO ’TYP-CE) 
(PNOOE ’TYP-CE)>) 

(./» ’ (NODE-TERflINRLS (BNODE ’TYP-CE)) 

<(BRSE (Q ’TYP-CE)) (#2 <R1 ’TYP-CE)) 

(#1 (R2 ’TYP-CE))>) 

(-/> ’(NODE-TERMINALS (ENOOE ’TYP-CE)) 

<(EMI (Q ’TYP-CE)) (#1 (RE ?TYP-CE))>) 

(./> ’(NODE-TERMINALS (CNODE ’TYP-CE)) 

<(COL (Q ’TYP-CE)) (#2 (RL ’TYP-CE))>) 

(«/> ’(NOOE-TERMINALS (PNODE ’TYP-CE)) 

<(#1 (R1 ’TYP-CE)) (#1 (RL ?TYP-CE))>) 

(»/> ’(NODE-TERMINALS (GND ’TYP-CE)) 

<(#2 (R2 ’TYP-CE)) (#2 (RE ’TYP-CE))>) 


jFROZEN TASKS 

(/:PLRN-INSTRNCE (FROZEN-BIRS-PLAN ’TYP-CE) 

(TYPICAL-BJT-ONE-STAGE-BIAS (Q ’TYP-CE)) 

(BIRSER (Q ’TYP-CE) RCTIVE)) 

</:REOUCED (BIRSER (Q ’TYP-CE) ACTIVE)) 

(FUNCTION (R1 ’TYP-CE) (BVO (FROZEN-BIRS-PLAN ’TYP-CE))> 
(FUNCTION (R2 ’TYP-CE) (BVD (FROZEN-BIAS-PLAN 7TYP-CE))) 
(FUNCTION (RE ’TYP-CE) 

(RESIS-GETTER (FROZEN-BIRS-PLAN 7TYP-CE)») 


(STASK (PORT-CVT ’TYP-CE) (OEEP-FREEZE 7TYP-CE) <> 
(\ () (CONVERT-PORT (OUTPORT ’TYP-CE) 

CURRENT VOLTAGE) > 

<>) 

(FUNCTION (RL ’TYP-CE) (PORT-CVT 7TYP-CE)) 

(EXPRNSION-OBL ’TYP-CE (FIX ’(V (PNODE 7TYP-CE)))) 
(/:SUBTASK (OBL ’TYP-CE (FIX ’(V (PNODE 7TYP-CE)))) 
(BIASER (Q ’TYP-CE) ACTIVE)) 

(CONSTRAINT <’(POLARITY (Q ’TYP-CE)) 

’(SIGN (V (PNODE 7TYP-CE)))> 

= > 

(CONTROL V-GAIN ’TYP-CE (INTERVAL -50 58) 2) 
(CONSTRAINT <’ (V-GAIN 7TYP-CE) MR (RL 7TYP-CE)) 
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’(R (RE ?TYP-CE))> 

(LRHBOR (RV RL RE) (. ?RV (// ?RL ?RE)) )) 

>1 

GENERAL-DP*> 


(DEFHLfl BRSIC-VO CBRSIC-DEV-TYPE VD1 > 

(OEFHLR VO-OEFN 

(-/> R (OEV-TYPE ’VO VO) 

(/iPKT VO-PKT (?V0) 

(COHPONENTS ?V0 <(R1 ?VO) <R2 ?VD)>) 

(NODES ?VO <(TOP ?VO) (HID ?VO) (BOT ?VO)>) 

(HRIN-OEV-TYPE (R1 ?VO) RESIStOR) 

(HRIN-OEV-TYPE (R2 ?VO) RESISTOR) 

U/> ’ (NOOE-TERHINRLS (TOP ?VD)) <(#1 <R1 ?VO))») 
(./> ’(NOOE-TERHINRLS (HID ?VO)) 

<(#2 (R1 ?VD)) (#1 (R2 ?VO))>) 

(=■/» ’(NOOE-TERHINRLS (BOT ?VO)) 

<(#2 (R2 ’VO))>) 

(OEV-TERHINRLS ?VD 

<(T0P ?VO) (HIO ’VO) (BOT ?VO)>) 


jFROZEN TASKS 

(EXPRNSION-OBI ?VO (FIX ’(V (TOP ?VO))>) 
(EXPRNSION-OBL ’VO (FIX ’(V (BOT ?VO>))) 

(CONSTRAINT <’(V (TOP ’VO)) ’(V (BOT ?VD>> 
’(V (HIO ’VO)) 

’(R (R1 ?VO)) ’(R (R2 ?VO))> 
(\ (VI V2 V R1 R2) 

(= ’V (// (+ (* ?R2 7V1) (* ’Rl ?V2)) 
(♦ ?RI ?R2))) )) 


)] 


(CONSTRAINT <’(I (HIO-NOOE ?V0)) 

’(I (#2 (Rl ’VD)))> 

(\ (I ID (/</< (RBS ’I) (RBS ’ID) )) 
(CONSTRAINT <’(I (HIO-NOOE ?VDD 
’(I (#1 (R2 ?VO)))> 

(\ (I 12) (/</< (RBS ’!> (RBS ?I2D )) 

GENERAL-OP*) 


(DEFHLfl RCQ-VO (NOT (REUSABLE VOID 
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|RS UITH CE, THERE IS RN RBSTRRCT ECP WHICH IS R CURRENT RHRLIFIER 
(DEFHLfl BRSIC-ECP IBRSIC-OEV-TYPE ECP)) 

(OEFHLR ECP-IS-RMP ISUB-DEV-TYPE ECP RMPLIFIERJ) 

. iFHLfl HOST-GENERRL-ECP IflOST-GENERRL-SPEC ECP GENERRL-ECP)) 
(OEFHLR ECP-DEFN 

t-/> R (DEV-TYPE ?ECP GENERRL-ECP) 

(/:PKT ECP-PKT (?ECP) 

(COMPONENTS ’ECP <(Q1 ?ECP> (Q2 ’ECP)>) 

(NODES ’ECP <(EN0DE ’ECP) 

(BNOOE1 ’ECP) (BNO0E2 ?ECP> 

(CN0DE1 ’ECP) (CNODE2 ’ECP)>) 

(MRIN-OEV-TYPE (Q1 ’ECP) BJT) 

(MODE (Q1 ’ECP) ACTIVE) 

(MRIN-OEV-TYPE (Q2 ’ECP) BJT) 

(MODE (Q2 ’ECP) ACTIVE) 

(»/> ’(NOOE-TERMINRLS (ENOOE ?ECP)) 

<(EMI (Qi ’ECP)) (EMI (Q2 ’ECP))>) 

(»/> ’(NOOE-TERMINRLS (BNOOE1 ’ECP)) 

<(BRSE (Ql ’ECP))>) 

(*/> ’(NODE-TERMINRLS (BN0DE2 ’ECP)) 

<(BRSE (02 ’ECP))>) 

(=>/> ’(NOOE-TERMINRLS (CNOOEl ’ECP)) 

<(COL (Ql ’ECP))>) 

(=/> ’(NOOE-TERMINRLS (CN00E2 ’ECP)) 

<(COL <Q2 ’ECP))>) 

(PORTS ’ECP <0UTP0RT-1 0UTP0RT-2>) 

(V-PORT (INPORT ’ECP)) 

(PORT-TERMINALS (INPORT ’ECP) 

<(BNODEI ’ECP) (BN00E2 ?ECP)>) 

(I-PORT (OUTPORT-I ’ECP)) 

(PORT-TERMINRLS (OUTPORT-I ’ECP) 

<(CN0DE1 ’ECP) (ENOOE ?ECP)») 

(I—PORT (OUTPORT-2 ?ECP>) 

(PORT-TERMINRLS (OUTPORT-2 ’ECP) 

<(CN0DE2 ’ECP) (ENOOE ?ECP)>) 

(/:SUBTflSK (BIRSER (Ql ’ECP) ACTIVE) 

(DEEP-FREEZE ’ECP)) 

(/:SUBTRSK (BIRSER (Q2 ’ECP) ACTIVE) 

(DEEP-FREEZE ’ECP)) 

(EXPRNSION-OBL ’ECP (FIX ’(I (ENOOE ’ECP)>)))1) 
(OEFHLR DEFRULT-ECP IOEFRULT-SPEC ECP ECP-OC-RMP)) 



(DEFHLR DERIVED-ECP-DC-AMP IDERIVEO ECP-DC-RHP ECP1) 

(DEFMLA ECP-DC-AMP-DEFN 

1/iANTEC (NOT (DEV-TYPE 7TYP-ECP ECP-OC-AMP)> 

(/sPKT ECP-OC-RMP-PKT (7TYP-ECP) 

(COMPONENTS 7TYP-ECP 

<(Q1 ?TYP-ECP) (02 7TYP-ECP) 

(Rl 7TYP-ECP) (RE ?TYP-ECP)>) 

(DEV-TYPE (RL 7TYP-ECP) RESISTOR) 

(DEV-TYPE (RE 7TYP-ECP) RESISTOR) 

(OEV-TYPE (01 HYP-ECP) BJT) 

(OEV-TYPE (02 7TYP-ECP) BJT) 

(MODE (01 7TYP-ECP) ACTIVE) 

(I100E (02 nYP-ECP) RCTIVE) 

(NODES 7TYP-ECP 

< (ENOOE nYP-ECP) (LOUNOOE 7TYP-ECP) 

(HIGHNOOE ’TYP-ECP) 

(C2N00E 7TYP-ECP) (B1N00E 7TYP-ECP) 

(B2N0DE ?TYP-ECP)>) 

(./> ’(NODE-TERMINALS (ERODE 7TYP-ECP)) 

<(EMI (01 7TYP-ECP)) (EMI (02 7TYP-ECP)) 

(#1 (RE 7TYP-ECPJ)>) 

(=/> ’ (NOOE-TERMINRLS (LOUNOOE 7TYP-ECP)) 

<(#2 (RE 7TYP-ECP)>>) 

(»/> ’(NOOE-TERMINRLS (HIGHNOOE 7TYP-ECP)) 

<(COL (Q1 7TYP-ECP)) (#1 (RL ?TYP-ECP))>) 

(■/> ’(NOOE-TERMINRLS (C2N00E 7TYP-ECP)) 

< (COL (02 7TYP-ECP)) (#2 (RL ?TYP-ECP))>) 

(»/> ’(NOOE-TERMINRLS (B1N00E 7JYP-ECP)) 

<(BRSE (01 7 TYP-ECP))>) 

(=■/> ’(NOOE-TERMINRLS (B2N00E 7TYP-ECP)) 

<(BRSE (02 ?TYP-ECP))>) 

jTHESE ARE URYS OF DOING TASKS IN ABSTRACT ECP... 

(EXPANSION-OBL 7TYP-ECP 

(FIX ’(V (LOUNOOE 7TYP-ECP)))) 
(EXPRNSION-OBL 7TYP-ECP 

(FIX ’(V (HIGHNOOE 7TYP-ECP)))) 

(REDUCE <(OBL 7TYP-ECP 

(FIX ’(V (LOUNOOE PTYP-ECP))))> 

(OBL (SOUL 7TYP-ECP) 

(FIX ’(I (ENOOE (SOUL 7TYP-ECP)))))) 

(REDUCE < (OBL 7TYP-ECP 

(FIX »(V (HIGHNOOE 7TYP-ECP))))» 
(BIRSER (01 (SOUL 7TYP-ECP)) ACTIVE)) 
(REOUCE <(OBL ’TYP-ECP 

(FIX ’(V (HIGHNOOE ?TYP-ECP))))> 
(BIRSER (02 (SOUL 7TYP-ECP)) ACTIVE)) 


(STRSK (CVT-PORT 7ECP) (OEEP-FREEZE 7TYP-ECP) 
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<> <\ () (PORT-CONVERT (OUTPORT PTYP-ECP) 
CURRENT VOLTfiGE) ) <>) 
(FUNCTION (RL ’TYP-ECP) (CVT-PORT PECPI) 

(FUNCTION (RE ’TYP-ECP) 

(OBL (SOUL PTYP-ECP) 

(FIX ’(I (ENOOE PECP))))) 

(CONSTRAINT <’(I (RE ?TYP-ECP))> 

(\ (!) (. PI 0.062) )) 

(CONSTRAINT <’(I (COL (Q1 ?TYP-ECP))I 
’(I (COL (Q2 PTYP-ECP)))> 

=>)))) 


(DEFflLA RC-OEV-TYPE 

C-/> fl (DEV-TYPE ’RC RC-FILTER) 

(/iPKT RC-PKT (?RC) 

(DEV-TYPE ’RC SIG-TRRNSER) 

(COMPONENTS PRC <(R1 >RC) (Cl PRC)>) 

(NODES PRC <(NOOE1 ’RC) (N00E2 PRC) (NODE3 ?RC)>) 

(./> ’ (NODE-TERMINALS (NODE1 ’RC>) <(fl (R1 PRC))>) 

(«/> ’(NODE-TERMINALS (N00E2 ?RC)> 

<(#2 (R1 ?RC)> (#1 (Cl ?RC))>) 

(»/> ’ (NODE-TERMINALS (NODE3 ?RC>> <(#2 (Cl ?RC))>) 

(V-PORT (INPORT PRC)) 

(PORT-TERMINALS (INPORT PRC) <(N0DE1 PRC) (N00E3 PRC)>) 
(V-PORT (OUTPORT PRC> > 

(PORT-TERMINALS (OUTPORT PRC) <(NOOEZ PRC) (NOOE3 ?RC)>) 

(CONTROL CUTOFF-FREQ PRC POS-REALS 1) 

(CONTROL (H PS) PRC COMPLEX 1.2) 

(CONSTRAINT <* (CUTOFF-FREQ PRC) 

’(R (R1 PRC)) ’(C (Cl ?RC))> 

(\ (F R C) (» ?F (// 1 (* PR PC))) )) 

(CONSTRAINT <’((H PS) ?RC) ’ (R (R1 PRC)) ’ (C (Cl PRC))> 

(\ (H R C) (. PH (// 1 (+ 1 (* ?R ?C PS)))) )) 

))) 


IT 
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Appendix 4 -- Details of STP for Theorem Provers 

The main requirement for an information-retrieval theorem prover is that 
it halt. This is hard because it must return as many answers as possible. If 
the theorem prover were the top level, as i 9 usually the case, we could just 
let it run until we ran out of money or patience, but the problem solver above 
it needs its answers in a finite time. STP has been written with thi.s 
emphasis in mind; in its design, I have sacrificed "completeness" to this 
"finiteness" requirement. 

STP is organized as a backward-chaining PLANNER-1 ike system. (Moore, 1975) 
Given a goal, it finds implications to back through. For example, with the 
goal "Refute [NOT (P ?X)]," it might back through [-/> C (AND (Q ?X) (R ?X)) 

(P ?X)1, which is internally stored as the disjunction [/:C0NSEQ (P ?X) (NOT 
(AND (Q ?X) (R ?X)))]). The reason implications are internally disjunctions 
is that STP wants to retrieve /:ANTECs in the same fetch as /:C0NSEQs. so it 
must put the index pattern in the same place. It is for this reason that 
atomic data are stored as t/:C0NSEQ |pat| FALSE!. 

This backward chaining creates a conjunction of subgoals, each of which is 
treated similarly to the way the top-level one was. The other subgoals are 
held in abeyance while the chosen one is worked on. This is called 
splitting " for reasons I will explain below. The chosen subgoal can sprout 
new subgoals, so the conjunction grows. 

Uhen a subgoal is reduced to FALSE, the resulting answer substitution is 
applied to the remaining conjuncts before they are split. Uhen there aren’t 
any more, the substitution is the final result. I will say more about "answer 
substitutions" below. 

Backtracking is necessary because there may be more than one split, and 
because there may be more than one answer to try on remaining conjuncts. 
Backtracking is implemented by saving the theorem-prover state when such a 
choice arises; and restoring such states when branches run out of choices, and 
after each top-level answer has been found. 

To limit backtracking, failures are not allowed to cause backtracking to 
an irrelevant choice point. Splits, when generated or augmented, are 
partitioned into split groups," each member of which i 9 a conjunction which 
shares no free variables with the others. (Ernst, 1973, Moore, 1975) For 
example, if [-/> C (AND (P ?x) (Q ?y)) (R ?x ?y)], the goal [NOT (R ?u ?v)] 
gives rise to two independent subgoals [NOT (P ?u)I and [NOT (Q ?v)]. All the 
answers are found to each, and the result is the "Cartesian product" of the 
answer sets of each. That is, if [P a) and [P b!, and [Q c! and [Q d! are 
present, [R a c), [Rad], [Rbcl, and [R b d) are deducible. 

A request to STP with free variables is interpreted as a demand for values 
of those variables which refute the request. In the example I just gave, the 
request [NOT (R ?u ?v)] is satisfied by four such sets. These are called 
answer substitutions. They are computed from the history of the matches from 
the original request to the instances of [FALSE! that are ultimately derived. 
For example, given the request [NOT (P ?x ?y)] and the axioms [/;CONSEQ (P ?u 
B) (NOT (Q ?u))! and [/:C0NSEQ (NOT (Q A)) FALSE!, the first backward chain to 
[NOT (Q ?x)] constrains ?y to be IB!; the chain to [FALSE! then sets ?x to 
[A!. 

This bookkeeping is handled in STP by use of the Boyer-Moore 
representation of clauses. (Boyer and Moore, 1972) The idea is to represent 
every clause as a pattern plus substitution. The substitution is called an 
environment. A formula represented thi9 way is called a closure. Matching 



Appendix 4 


252 


two closures creates a new, more constrained environment which describes the 
new substitution as a further specification of the two old ones. In this way, 
each environment really specifies a binary tree of super-environments which 
parallel its deductive history. Boyer and Moore explain how a numerical 
"environment id" or envid can specify any branch of this tree. Giving two 
envids specifies the node where the two branches meet. 

STP uses this device to keep track of answers to goals. The variable ANS- 
ENVID* specifies the envid of the current main goal. The variable. MAIN-MAX* 
specifies the size of the tree above the main goal’s environment; that is, 
ANS-ENVID* and ANS-ENVID* + MAIN-MAX* are two envids which uniquely specify 
the environment of the main goal. The function ENV-COLLAPSE takes the 
environment of a terminal [FALSE] and these two numbers and produces an 
environment with all the discovered constraints recorded. This mechanism 
makes unnecessary the "answer-predicate" construct of (Green, 1969).. 

Of course, this mechanism is more specialized than Green's, since it is 
not able to return "disjunctive" substitutions. Thus, it will not work if the 
request [NOT (P ?X) 1 appears with [/:C0NSEQ (P A) (P B)], even though these 
formulas are provably inconsistent. (The (P B] detached by the first 
resolution matches the original goal.) It won’t work because there is no 
assignment of one value to X which refutes (NOT (P ?X)1. This is not really a 
deficiency in doing information retrieval, but we must be careful to detect 
it. I will say how this is done after a short digression. 

STP is a refutation-driven theorem prover. This means that it doesn't 
just back through implications, it also records the formulas it is trying to 
refute so that they can take part in deductions. When the prover returns, al I 
of these effects must disappear. This is accomplished by "pushing" the 
current data pool, doing recording formulas in it, and "popping" at the end. 
(McDermott and Sussman, 1973) This is done for every subgoal as well. 

Now the machinery can allow several kinds of interactions between goals. 
The kind I mentioned two paragraphs ago is called "befuddIement." This is when 
two matching subgoals specify conflicting substitutions. This is handled by a 
program (TP-STATUS-RECONCILE), which forces agreement between two conflicting 
lines of deduction; it insists that just one ANS-ENVID* be passed along. 

Another kind of interaction is subsumption. If a new goal is subsumed by 
a fact not in the pushed data pool, it is abandoned. For example, even if 
there are axioms for proving (P ?X], there is no point in trying to prove (P 
Al (that is, refute (NOT (P A)]), if (NOT (P A)1 is in the data base. If you 
succeeded in deriving such a proof, it would be of little value, since it 
would just prove the inconsistency of the data base with regard to this 
question. 

More interesting is the case where the subsumer is another goal. This 
case must be noticed, since the subsumer may be a super-goal of the current 
one, and therefore an infinite recursion may be impending. In any case, there 
is usually no point in proceeding, so STP abandons this goal. (This puts the 
program even further from deductive completeness.) However, there is an 
important case in which mere abandonment is not enough. If the super-goal is 
a main super-goal which is a variant of the current one, the answers to the 
super-goal must be applied to this one. For example, given the axioms 

(/:C0NSEQ (ABOVE ?X ?Y) (NOT (ON ?X ?Y))3 
[/:CONSEQ (ABOVE ?X ?Z) 

(NOT (AND (ABOVE ?X ?Y) (ON ?Y ?Z)))] 
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C>] and [NOT (P X!G9)]. The first subgoal becomes, via the definition of ELT, 
COR (=/> X!69 A) (=/> ’X!G9 B) (=/> ’X!G9 C)]. When this is split, the first 
subgoal generated is [=/> ’X!69 A], The only effect this can have is by 
substitution, so the system finds all formulas that mention X!G9 and does the 
indicated replacements. (There won’t be very many, because X!69 is a new 
skolem form.) In this case, the subgoal [NOT (P A)] will be generated! 

Similar things will happen in the other two branches of this split. To make 
this work requires a bit of mechanism not usually implemented in theorem 
provers; the data-base machinery of (McDermott, 1975) must be augmented so 
thgt from any pattern one can retrieve all the formulas which contain it. 

This is done by keeping track of all the positions an atom appears in, and 
intersecting the index buckets corresponding to atom positions compatible with 
the pattern. 

Modality — Complications are introduced by the use of data pools to 
implement "reference points." (Sect. II.B.2) When the system has a goal of 
the form [T |ref| |fact|l, it attempts to "coerce" the ref into a data pool. 

It then pushes this data pool as it did the calling one, and puts the fact 
into it for refutation. 

Data Dependencies — STP keeps track of the data that support its 
conclusions. Its caller will use these to build data dependencies as 
described in Sect. II.D. The only tricky part to this is to make sure the 
data pools are kept straight. Whenever working on a [T...I expression causes 
a jump to a new pool, the supporters will be packaged up in the form (OD-T 
Ipool name| |fact|). These ultimately end up in this form in the 
dependencies. (See Sect. II.D.) 

Life with Boyer and Moore — J Moore has informed me (personal 
communication) that several people have used their representation for clauses. 
(1972) For the benefit of those tempted to use it, I should report my 
experiences with it. 

My original motivation for wanting to represent formulas as closures was 
to preserve a perspicuous representation of goals for interaction with advice. 
The usual predicate-calculus theorem prover renames all the variables in two 
formulas before unifying them;, this is called "standardizing them apart." 

Boyer and Moore’s motivation was to save storage by representing clauses 
incrementally, as the differences between input clauses and output clauses of 
deductions. 

Neither of these reasons turned out to be important, so that this is a 
classic example of the dangers of bottom-up programming, or anticipating 
problems that never arise or are swamped by other effects. As I discussed in 
Sect. VI.B, my deductive goals never interact with advice anyway; and Boyer 
and Moore’s effort to save storage is wasted in a system, like mine, which 
must index each clause atom by atom. (Actually, the system is not quite that 
stupid, but I think any savings incurred are minute.) 

On the other hand, the representation has proven to have several very 
natural uses. The packet machinery of (McDermott, 1975) "actualizes" 
potential items by just replacing the potential environment with the real one. 
The answer calculation described above is completely natural in a system that 
represents clauses by their deductive histories. The evaluation machinery 
that tries to evaluate only subexpressions with newly instantiated variables 
operates by traversing the expression to be evaluated, comparing variable 
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values in the old environment with those in the new. 

On balance, my conclusion is that these advantages do not outweigh the 
disadvantages, which are considerable. The principal one is that CAR and CDR 
are useless for operating on closures. You cannot take the first step into a 
closure without setting up its environment. Every function that manipulates 
them must treat assigned variables as though they were transparent (i.e., go 
straight to their values); and correctly handle envid’s that direct attention 
to the proper parts of the environment tree. Boyer and floore show in their 
paper that it is easy to write a unification algorithm for closures. •Indeed, 
it is easy to write any one algorithm, but the fact that every manipulation 
has to take the same tedious cases into account is something I didn't foresee. 

I solved this problem to some degree by writing a set of functions (with names 
like FMAP and FHACK) which (analogously to LISP’s (1AP functions) map 
operations over Boyer-Moore data structures. But these functions have to bind 
special variables and use MACLISP functional arguments, so they are of 
necessity quite slow. To get the CAR of a formula, you have to write (FHACK 
(FUNCTION CAR) FMLA); this binds two special variables, does an uncomp liable 
property-list lookup on CAR, and still returns an object (such as " (^F-CLOSURE 
(P ?X) 3) ) which is meaningless without further bit-picking in the formula's 
environment tree. 

Alas, these problems are complicated an order of magnitude by interact ions 
with segment forms and embedded formulas. (See Appendix 1.) Processing an 
embedded formula often requires setting up a stack of environments, which is 
pushed and popped as you go into a pair of brackets or encounter an escape 
form. 

Finally, it is very hard to develop intuitions about the structure of 
environment trees. A buggy program that manipulates envids doesn’t do 
anything radically different from a correct program; it's just looking at the 
wrong parts of the environment tree. The envids it uses are just little 
.integers with little meaning. Debugging such a program usually comes down to 
experimenting with different numbers until something works! 
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